United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-4558797 : "Copy" operation fails when using "xclipboard"

Details
Type:
Bug
Submit Date:
2001-12-07
Status:
Resolved
Updated Date:
2002-10-18
Project Name:
JDK
Resolved Date:
2002-10-18
Component:
client-libs
OS:
solaris_8
Sub-Component:
java.awt
CPU:
sparc
Priority:
P5
Resolution:
Fixed
Affected Versions:
1.4.0
Fixed Versions:
1.4.2 (mantis)

Related Reports
Relates:
Relates:

Sub Tasks

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


                                     
2004-06-14
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


======================================================================
                                     
2002-09-27
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
======================================================================
                                     
2002-09-04



Hardware and Software, Engineered to Work Together