Weird copy and paste bug involving multiple instances of Geany

[chrisgraham]

If I open a second instance of Geany, copy something to the clipboard, close that instance, and then try and paste into that second instance, nothing happens. This is using the drop-down menu, the context menu, and ctrl+v.
However, I can then paste into other applications and it works fine.
So somehow there is some issue with Geany accessing clipboard data from a closed version of itself that other applications don't suffer.

[codebrainz]

It works fine here with Geany 1.37 (master) on Ubuntu 20.04 in Gnome/X11 as well as Geany 1.36 on Windows 7. Perhaps it's a bug in your unspecified version of Geany or OS.

[chrisgraham]

Sorry, I should have specified those things, mind fart on my part.

geany 1.37 (git >= fe7d2f87) (built on 2020-03-21 with GTK 2.24.32, GLib 2.62.1)
As it says, it is a custom build - but not very custom, and certainly I've not been messing with GTK stuff.

lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 19.10 Release: 19.10 Codename: eoan

If it's not reproducible I might have a closer look myself.

[elextr]

WFM, Linux Mint (Ubuntu 18.04) Cinnamon Geany 1.37 (git >= 82590af), en_AU.UTF-8 GTK 3.22.30, GLib 2.56.4

[codebrainz]

@chrisgraham are you using Wayland do you know?

[chrisgraham]

No I'm not.
I'm actually looking into it now, but I don't have a whole lot of time so I suspect I'll get nowhere.
Issue is likely in Scintilla IMO.
Happens even if I use a clipboard manager and can see the current clipboard within it!
Happens even if I close all Geany instances and open a new one and try and paste into that.

I wonder if it is related to https://bugs.gentoo.org/189230 (which is https://sourceforge.net/p/scintilla/bugs/626/).

Edit: I can actually also reproduce with just one instance. Copy something, close it, open it, and paste fails (but paste works in anything else).

[elextr]

Might be a GTK 2 thing, @chrisgraham can you build a GTK 3 version to try?

[chrisgraham]

Noted. I can say with my debugging so far that gtk_selection_data_get_length is returning -1 for my test case and ScintillaGTK::InsertSelection has a branch check on >=0.

EDIT interesting, seems to be reading invalid memory if I try and then call gtk_selection_data_get_selection:

Thread 1 "geany" hit Breakpoint 2, Scintilla::ScintillaGTK::ReceivedClipboard (this=0x55555615cce0, selection_data=0x7fffffffd720)
    at gtk/ScintillaGTK.cxx:1458
1458	void ScintillaGTK::ReceivedClipboard(GtkSelectionData *selection_data) noexcept {
(gdb) p (gint)gtk_selection_data_get_length(selection_data)
$7 = -1
(gdb) p (GdkAtom)gtk_selection_data_get_selection(selection_data)
$8 = (GdkAtom) 0x45
(gdb) po (GdkAtom)gtk_selection_data_get_selection(selection_data)
[Thread 0x7fffef7fe700 (LWP 26266) exited]
Cannot access memory at address 0x45

EDIT: It's not invalid memory, just gdb cannot get at MMAPed memory (I think).

[chrisgraham]

I really tried hard to debug this, and I'm completely stuck.

I can clarify the bug. It's definitely at least partly a Scintilla issue, not specific to Geany. I can reproduce it in MySQL Workbench (which I've most definitely not compiled myself).

GTK3 vs GTK2 is not an issue (of note I was on GTK2 as the configure script for geany will default to that if both are available). Clipboard saving was added to GTK 2.6, and is working just fine, because I can paste text from a closed Geany instance into other apps.

And it's not directly an issue with pasting from a closed program. It's an issue of pasting via the old-school X11 clipboard, which is invoked if the program has been closed. If I try and copy and paste in from NEdit (old X11 text editor) it won't paste even when NEdit is still running.

EDIT: Actually NEdit is a red herring. The issue there is it doesn't save to the clipboard with a utf-8 target, and Scintilla/GTK both assumes utf-8.

It's only with the Scintilla editing area. Pasting into say 'find in files' works just fine.

I debugged this all the way down to the call to XConvertSelection. But I couldn't poke around much at this level because (and this is where I get very out of my depth) I think the libx atom memory is MMAPed and gdb cannot get at it.

My best guess is something incorrect is being passed down from Scintilla via GTK to XConvertSelection, causing Xorg to not respond.

I couldn't work out any way to set up verbose Xorg logging to see if it would give any errors.

I am on a 3-monitor system.

(II) RADEON: Driver for ATI/AMD Radeon chipsets:
        ATI FirePro V7760 (FireGL), ATI Mobility RADEON HD 4850,
        ATI Mobility RADEON HD 4850 X2, ATI FirePro RV770,
        ATI Mobility RADEON HD 4870, ATI Mobility RADEON M98,
        ATI FirePro M5750, ATI RV730XT [Radeon HD 4670], ATI RADEON E4600,
        ATI RADEON E2400, ATI FireMV 2260, ATI RV670, ATI Radeon HD3870,

I probably spent way more time than this bug is worth, but I got obsessive :S.

[elextr]

I probably spent way more time than this bug is worth, but I got obsessive :S.

Thanks very much for trying anyway, without being able to reproduce it I'm not sure what else we can do right now.

[chrisgraham]

I don't know if it is relevant, but my logged in X11 session is vt2, and the gdm login screen is on vt1. i.e. I can ctrl+alt+f1 and it will go to the login screen, and it will then click back to vt2 after re-logging in.
This is the 'default' on my system (i.e. I haven't knowingly done anything to make it this way).
I wonder if this could be something that messes with the display context passed through to the X server for pasting.
Does anyone else have this same setup?

[chrisgraham]

Fixed upstream https://sourceforge.net/p/scintilla/bugs/2175/ :)