JDK-4643942 : Deadlock while performing "javax.swing.JTextComponent.copy"
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 1.3.1_02
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: linux_redhat_7.1
  • CPU: x86
  • Submitted: 2002-02-27
  • Updated: 2002-03-04
  • Resolved: 2002-03-04
Related Reports
Duplicate :  
JDK-4558745 - Deadlock occurs while copying
Relates :  
JDK-4388802 - Drag and drop is raising exception for JList
Description
Sometimes (not 100% reproducible, but happens) while performing copy action in NetBeans IDE a deadlock occurs (full thread dump is attached).

As original report can be considered this:
http://www.netbeans.org/issues/show_bug.cgi?id=20836

The system is Linux, RedHat 7.1, "2.4.9 #4 SMP".
The JDK is (java -version):
java version "1.3.1_02"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_02-b02)
Java HotSpot(TM) Client VM (build 1.3.1_02-b02, mixed mode)
Comments
EVALUATION I put the thread dump (from the web page) in the Comments section. Since both the toolkit and EDT threads are passing through sun.awt.motif.X11Selection I'll reassign this to Drag&Drop. BTW, I saw the following comment in the web page: > I will close this bug until JDK team will evaluate it. I think that we > can not call JTextComponent.copy out of AWT thread, as I have neither > found that this method is thread safe (and swing methods should be > used only from AWT thread), nor this method is required to be called > outside of AWT thread. ###@###.### 2002-03-01 Name: dsR10078 Date: 03/04/2002 The deadlock is the same as the one documented under bug id 4558745. It happens as follows: The application is the current owner of CLIPBOARD selection. Some other application requests the list of supported selection targets. As of 1.3.1, the implementation is to request this list from the Transferable that represents the current clipboard contents. This involves execution of the client code, so for security reasons the toolkit thread that processes the request needs to post an InvocationEvent with the call to getTransferDataFlavors() to the Java event dispatch thread and wait 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 or "Copy" menu command. 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. ###@###.### 2002-03-04 ======================================================================
04-03-2002