JDK-4558745 : Deadlock occurs while copying
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 1.3.1_01,1.3.1_02
  • Priority: P4
  • Status: Closed
  • Resolution: Cannot Reproduce
  • OS: linux_redhat_7.1,solaris_8
  • CPU: x86,sparc
  • Submitted: 2001-12-07
  • Updated: 2002-12-09
  • Resolved: 2002-12-09
Related Reports
Duplicate :  
Relates :  
Relates :  
Relates :  
Relates :  
Description
The original bug report is:
http://openide.netbeans.org/issues/show_bug.cgi?id=12371
The deadlock is reproducible in combination of JEP (attached application) and "xclipboard" utility. The deadlock occurs in 20% of "copy" operations in case
using "xclipboard". In case not using "xclipboard" it is quite rare. Steps:
1. Run attached JEP application.
2. Run "xclipboard" utility.
3. Copy some text into JEP app.
4. Now, try to select and "copy" (Ctrk-C) the text in JEP.
5. Repeat step 4 until deadlock occurs.
6. From xclipboard dialog saying: "CLIPBOARD selection conversion failed"

The full thread dump is attached.
The JDK where the problem is reproducible is:
java version "1.3.1_01"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_01)
Java HotSpot(TM) Client VM (build 1.3.1_01, mixed mode)

I was not able to reproduce it on:
java version "1.4.0-rc"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-rc-b88)
Java HotSpot(TM) Client VM (build 1.4.0-rc-b88, mixed mode)

Comments
EVALUATION Name: dsR10078 Date: 12/13/2001 When xclipboard is started, it 1) requests the CLIPBOARD selection contents in text formats and 2) claims CLIPBOARD selection ownership and provides the requested data when the selection data is requested. After that whenever xclipboard looses selection ownership it executes steps 1) and 2). This deadlock is very similar to the hang described in the evaluation for 4388802. The deadlock occurs when the JEP application is the current CLIPBOARD selection owner. xclipboard requests the CLIPBOARD selection data. This request is processed on the toolkit thread (AWT-Motif). To process it we need to get the transfer data in one of supported data flavors by calling getTransferData() on the Transferable passed to setContents(). getTransferData() contains client code that should't be executed on the toolkit thread for security reasons (see 4380582). So the toolkit thread posts an InvocationEvent with the call to getTransferData() to the Java event dispatch thread and waits until this event is processed on that thread. At the same time the Java event dispatch thread (AWT-EventQueue-0) tries to acquire the CLIPBOARD selection ownership in response to Ctrl-C. In order to claim the selection ownership we need the current X server time to use it as a timestamp (see 4085183). To get the current X server time we use a technique suggested in the X11 Reference Manual: append a zero-length data to a property and wait until the PropertyNotify event is processed on the toolkit thread. At this moment the toolkit thread is waiting until the Java event dispatch thread processes InvocationEvent and the Java event dispatch thread is waiting until the toolkit thread processes PropertyNotify event. The fix for 4388802 resolves this problem so the deadlock doesn't occur with 1.4.0. That fix is to choose the toolkit thread as the deadlock victim in the conditions described above. The current implementation is to report the data conversion failure to the requestor when the deadlock conditions are detected. ###@###.### 2001-12-10 ======================================================================
10-12-2001