X11 selections (clipboard) stops working on long running X11 client using libgtk
Submitted by Thomas Ries
Link to original bug (#785842)
Description
Created attachment 356982 patch: Disabling the X11 timestamp wraparoung logic in clipboard_get_timestamp()
Observation: On long running xfce4-Terminal applications (like 30days +), copy/paste operations suddenly stop to work (actually the "copy" operation does not work anymore). This is true for X11 PRIMARY selections (middle mouse button) as well as CLIPBOARD selections (CTRL-C/CTRL-V style). A newly started xfce4 Terminal does not show this behaviour until it has been left running for a longer period of time.
Analysis: Tracing the X calls using xtruss, I was able to see that during a "copy" operation, the affected X11 client was sending wrong timestamps towards the X server (XSetSelectionOwner() call), causing the X server to discard this operation due to failing consistency checks of the timestamp value.
I seem to have traced it down to gtk+ clipboard handling, resp. gtk+ trying to "guess" a correct timestamp to pass with the XSetSelectionOwner() call. There is some "interesting" wraparound detection login in gtkclipboard.c (function clipboard_get_timestamp) that does not make sense to me (apologies, I may simply miss the point of why it is there, but IMHO it does cause the issue described).
Observed and tested with gtk2-2.24.23 (CentOS 6), but basically the same overflow login is still present in the master branch on github.
What happens in my case likely is:
- I have a long running X11 client like xfce4-Terminal that uses the clipboard functionality implemented in libgtk
- I do some copy/paste operations (PRIMARY ans CLIPBOARD selections)
- This causes the timestamp attribute inside the clipboard datastructure to be set to T1
- I do leave the application running for around 25+ days without doing copy operations
- Doing a new copy operation now triggers the "wraparound" login (due to the time difference bwetween T1 and now) in gtkclipboard.c (clipboard_get_timestamp), resulting that not the X11 CurrentTime is used but the old, stale T1 timestamp from the clipboard datastructure is used to perform the XSetSelectionOwner() call.
- To the X server, this timestamp looks as it is in the past and the call will not be honored, causing the copy operation to fail.
Using gdb I was able to attach to a process that showed this failure and could confirm my points above. Once I did (using the debugger) update the clipboard->timestamp value to a value close to CurrentTime (thus avoiding to trigger the wraparound logic), copy operations started to work again in this application.
I spent quite some time trying to figure out what the reason for this wrap-around handling could be, but did not come up with any meaningful result. In my opinion, XSetSelectionOwner(), etc calls towards the X server should use CurrentTime to avoid getting in trouble when the X server uses the timestamp value to eliminate race conditions (figuring out which is the most recent selection call).
I'm have patched my libgtk to completely exclude the wraparound logic and will observe things, hopefully not breaking something else.
Best regards, /Thomas
Attachment 356982, "patch: Disabling the X11 timestamp wraparoung logic in clipboard_get_timestamp()":
file_785842.txt
Version: 2.24.x