Bug 634094

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)

How reproducible:

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
   $ ./cut_paste&

2. Build and run the clipboard monitoring tool

   $ cc -Wall `pkg-config --cflags --libs gtk+-2.0` clipmon.c -o clipmon
   $ ./clipmon&
   
3. Type some text in the cut_paste window, select it and go to "Edit" and "Copy"
  
Actual results:

- 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

Expected results:

- 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

Additional info:

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).