Red Hat Bugzilla – Bug 634094
Copy/paste with Clipboard sometimes fails in 64bits because of timestamp issues
Last modified: 2016-04-18 06:20:57 EDT
Description of problem:
The issue has been reported in NEdit but is reproducible with any XmText widget. It is also affecting current OpenMotif from CVS upstream.
When using copy/paste with clipboard on a 64bits system, the clipboard fails to work randomly and pasting in another application retrieves no data.
Version-Release number of selected component (if applicable):
openmotif-2.3.1 (but any OpenMotif versio nexhibits the problem, including versions from CVS)
Always on a 64bit Red Hat Enterprise Linux 5 (use the local display and not a remote connection)
Steps to Reproduce:
1. Build and run the attached reproducer program
$ cc -o cut_paste cut_paste.c -I/usr/X11R6/include -lXm -lXt -lX11 -lc
2. Build and run the clipboard monitoring tool
$ cc -Wall `pkg-config --cflags --libs gtk+-2.0` clipmon.c -o clipmon
3. Type some text in the cut_paste window, select it and go to "Edit" and "Copy"
- From the clipboard monitor log, it shows that the clipboard value as text is NULL:
*** Selection for CLIPBOARD claimed by window 0x5c00021 with timestamp 98808006, value (as text) is now NULL
- Pasting in any other application does not work (ie no text is inserted when pasting) - Note, copy/paste to/from the same window works, because it uses a different mechanism
- From the clipboard monitor log, the actual value of the text copied is seen in the clipboard:
*** Selection for CLIPBOARD claimed by window 0x5c00021 with timestamp 98808006, value (as text) is "some text\nwhich was\ntyped" (total 25 characters)
- Pasting in another application inserts the text previously copied
Motif uses a property MOTIF_CLIP_HEADER set on the root window to store various params of the copy operation, including the timestamp of the X event which triggered the copy.
Looking at that property on a 64bit system when the copy fails show that the actual value used for the timestamp is negative:
$ xprop -root | grep MOTIF_CLIP_HEADER
_MOTIF_CLIP_HEADER(INTEGER) = 3, 0, 1, 64, 5001, 4001, 4001, 5001, 0, 2, -752856684, ...
The problem is this value gets converted back to a timestamp using the type "Time" and the resulting value is way too big. In libXt's Selection.c, in HandleSelectionEvents() the timestamp passed is compared to the current (real) timestamp, and the negative value is much larger than any possible real timestamp, causing the value copied to be cleared.
I believe this is the same as another bug found in metacity, wrt to Time being converted to 32bit unsigned internally in Xlib, see https://bugzilla.gnome.org/show_bug.cgi?id=348305
And also this comment from Owen in https://bugzilla.gnome.org/show_bug.cgi?id=115650#c43 reported below for readability:
"As for C, the issue is that CARD32 server side items are represented as longs in the Xlib API, but they still only have 32 bits of data in them."
And indeed using a CARD32 fixes the issue, copy/paste via the clipboard works fine even on 64 bits systems (proposed patch attached).
Created attachment 447407 [details]
Clipboard monitor tool
This is for debugging purpose.
Created attachment 447408 [details]
Any OpenMotif program would reproduce, this example is just to show that the problem lies in OpenMotif and not in the actual program.
Created attachment 447409 [details]
This patch fixes the issue by using CARD32 instead of Time for the timestamp internally.
This is similar to the fix applied in Metacity for the same problem (see comment #0).
Unlike what I stated initially in the description, the problem is actually random...
Sometimes it does not happen at all, but when it's started it remains as long as the X server is running, restarting Motif apps makes no difference.
When happening, only Motif apps are affected, copying from apps using other toolkits work. And only the clipboard selection, primary selection works as well (ie middle click button).
Created attachment 450973 [details]
Symptom patch of time problem in XtOwnSelection
This patch fixes the symptom of the time problem in XtOwnSelection in OpenMotif without changing function prototypes of AssertClipboardSelection and InitializeSelection.
To be able to reproduce this problem, you have to set a date between
"Tue Aug 17 14:22:18 CEST 2010" and "Sat Sep 11 02:37:31 CEST 2010"
It is also possible to use the date "Mon Oct 30 21:03:10 CEST 2010"
Then the time value of events in the server is bigger than INT_MAX.
Granting Devel ACK to get this out asap.
Thanks & regards, Phil
Created attachment 454754 [details]
This patch is similar to the patch in comment 7, but we make typecasting earlier after receiving data from X server.
Maybe it help to avoid similar potential issues.
Technical note added. If any revisions are required, please edit the "Technical Notes" field
accordingly. All revisions will be proofread by the Engineering Content Services team.
Due to 32-bit time stamp issues, attempting to copy and paste on a 64-bit architecture using the clipboard may have failed occasionally. With this update, the underlying source code has been modified to ensure the time stamp always contains a "CARD32" value, so that copy and paste on 64-bit architectures works as expected.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.