Bug 634094

Summary: Copy/paste with Clipboard sometimes fails in 64bits because of timestamp issues
Product: Red Hat Enterprise Linux 5 Reporter: Olivier Fourdan <ofourdan>
Component: openmotifAssignee: Thomas Woerner <twoerner>
Status: CLOSED ERRATA QA Contact: Filip Holec <fholec>
Severity: high Docs Contact:
Priority: urgent    
Version: 5.5CC: cww, fholec, ihayvuk, jwest, kem, pknirsch, psplicha, syeghiay
Target Milestone: rcKeywords: Patch, ZStream
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
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.
Story Points: ---
Clone Of:
: 647411 (view as bug list) Environment:
Last Closed: 2013-09-30 20:33:21 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On:    
Bug Blocks: 647399, 647411    
Attachments:
Description Flags
Clipboard monitor tool
none
Simpler reproducer
none
Proposed patch
none
Symptom patch of time problem in XtOwnSelection
none
Proposed patch none

Description Olivier Fourdan 2010-09-15 04:37:31 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)

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).
Comment 1 Olivier Fourdan 2010-09-15 04:39:49 EDT
Created attachment 447407 [details]
Clipboard monitor tool

This is for debugging purpose.
Comment 2 Olivier Fourdan 2010-09-15 04:41:20 EDT
Created attachment 447408 [details]
Simpler reproducer

Any OpenMotif program would reproduce, this example is just to show that the problem lies in OpenMotif and not in the actual program.
Comment 3 Olivier Fourdan 2010-09-15 04:43:15 EDT
Created attachment 447409 [details]
Proposed patch

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).
Comment 5 Olivier Fourdan 2010-09-15 12:23:38 EDT
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).
Comment 7 Thomas Woerner 2010-10-01 06:12:16 EDT
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.
Comment 8 Thomas Woerner 2010-10-01 06:59:37 EDT
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.
Comment 9 Phil Knirsch 2010-10-14 05:39:29 EDT
Granting Devel ACK to get this out asap.

Thanks & regards, Phil
Comment 12 Ihor Hayvuk 2010-10-21 05:17:51 EDT
Created attachment 454754 [details]
Proposed patch

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.
Comment 17 Jaromir Hradilek 2010-11-02 09:56:59 EDT
    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.
    
    New Contents:
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.
Comment 25 errata-xmlrpc 2013-09-30 20:33:21 EDT
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.

http://rhn.redhat.com/errata/RHBA-2013-1355.html