JDK-4558797 : "Copy" operation fails when using "xclipboard"
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 1.4.0
  • Priority: P5
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris_8
  • CPU: sparc
  • Submitted: 2001-12-07
  • Updated: 2002-10-18
  • Resolved: 2002-10-18
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
1.4.2 mantisFixed
Related Reports
Relates :  
JDK-4558745 - Deadlock occurs while copying
Relates :  
JDK-4760364 - X11: Deadlock when two apps request selection data from each other
Description
Using the same approach on JDK1.3.1, deadlock can occur (as described in bug #4558745). Problem described here was never reproduced in JDK1.3.1.
JDK version:
java version "1.4.0-rc"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-rc-b89)
Java HotSpot(TM) Client VM (build 1.4.0-rc-b89, mixed mode)

Steps to reproduce:
1. Run attached JEP application
2. run "xclipboard" application
3. Paste some text into the testing app.
4. Select some text
5. Try to perform copy operation (Ctrl-C)
6. Look into to the xclipboard for clipboard content, it is often empty. It is not possible to perform paste operation (nothing is in clipboard).
7. If problem does not occur, repeat steps 4, 5, 6.

This problem is not reproducible without "xclipboard".
The original bug report against NetBeans is here:
http://www.netbeans.org/issues/show_bug.cgi?id=18246
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mantis FIXED IN: mantis INTEGRATED IN: mantis mantis-b04
14-06-2004
SUGGESTED FIX Name: agR10216 Date: 09/30/2002 Remove DataTransferer.blockedEventQueues, DataTransferer.setBlockedMode() and call of this method in WDropTargetContextPeer, X11Selection, X11Clipboard, SunDropTargetContextPeer. ###@###.### 2002-09-27 ======================================================================
27-09-2002
EVALUATION Looks serious enough for Mantis. ###@###.### 2002-07-15 Name: agR10216 Date: 09/30/2002 The fix for the deadlock documented in 4558745 was to choose the toolkit thread as the deadlock victim and report data conversion failure to the selection data requestor. So the failure happens whenever the deadlock condition is detected. However, the current implementation of the secondary event loop prevents java from locking up in this situation. The secondary event loop is executed whenever the toolkit thread posts an event to the java event queue and waits until the event is processed by the event dispatch thread. The deadlock could happen if the event dispatch thread posts a synchronous request to the toolkit thread while the toolkit thread is in its turn waiting until this event dispatch thread processes a specific java event. The synchronous requests from the java event dispatch thread to the toolkit thread can be categorized as follows: 1.On Windows: - SendMessage calls from the event dispatch thread; - WM_AWT_INVOKE_METHOD messages processed synchronously - used by the following methods of WDropTargetContextPeer: - getData() - Available() - Read() - ReadBytes() - Close() 2.On Solaris/Linux: - MDropTargetContextPeer.getNativeData() sends a request for the drop transfer data and waits until the toolkit thread processes a specific SelectionNotify event that notifies that the request is processed; - X11Selection.pGetSelectionOwnership() calls awt_util_getCurrentServerTime() that causes the calling thread to wait until the toolkit thread processes a specific PropertyNotify event; - Solaris/Linux implementation of getClipboardFormats() and getClipboardData() in ClipboardTransferable send a request to the selection owner and waits until the toolkit thread processes a specific SelectionNotify event that notifies that the request is processed. On Windows the secondary event loop processes all sent messages and WM_AWT_INVOKE_METHOD. On Solaris/Linux it processes SelectionNotify and PropertyNotify events. So all possible synchronous requests from the event dispatch thread to the toolkit thread are processed even if the toolkit thread is currently waiting for this event dispatch thread to process a specific java event. This allows to remove the code that detects deadlock conditions. ###@###.### 2002-09-04 ======================================================================
04-09-2002