JDK-4532299 : Neverending loop in sun.awt.datatransfer.SunClipboard.getContents
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 1.4.0
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: linux
  • CPU: x86
  • Submitted: 2001-11-28
  • Updated: 2002-01-21
  • Resolved: 2001-12-20
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.
1.4.0 rc1Fixed
Related Reports
Relates :  
Relates :  
The NetBeans/Forte IDE gets to a state where you have to kill it.
 I am able to reliably reproduce the behaviour in my setup:  

  Product Version       = NetBeans IDE, Development Version (Build 200111261006)
  IDE Versioning        = IDE/1 spec=1.43 impl=200111261006
  Operating System      = Linux version 2.4.5 running on i386
  Java; VM; Vendor      = 1.4.0-rc; Java HotSpot(TM) Client VM 1.4.0-rc-b87; Sun Microsystems Inc.

How to reproduce:
1. Get a beta build of NetBeans 3.3 IDE
2. Start it
3. Locate the MemovryView example, change the type of execution to External Execution
4. Run the Memory View example
5. From the runtime tab try to "Terminate Process"
(if it does not crash emmediately repeat steps 4. and 5. - I am able to reproduce it with less than 3 attempts)

My Linux configuration is standard RedHat 7.1 with kernel 2.4.5 and
JDK 1.4.0-rc-b87.

Thread dump is attached. Please see the "exec_MemoryView_3" thread - it is consuming 100% of my CPU time. 

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: merlin-rc1 FIXED IN: merlin-rc1 INTEGRATED IN: merlin-rc1 VERIFIED IN: merlin-rc1

EVALUATION Reassigning to drag&drop, since the Synopsis claims the loop is in clipboard code. ###@###.### 2001-11-28 Name: dsR10078 Date: 11/29/2001 The bug is reproducible on Redhat 6.2 with merlin b87. ###@###.### 2001-11-29 ====================================================================== Name: dsR10078 Date: 12/04/2001 The hang happened when the "exec_MemoryView_3" thread was interrupted while executing ClipboardTransferable.getClipboardFormats(). It was interrupted from DefaultSysProcess.stop() invoked when "Terminate Process" is selected. Actually the hang happens whenever the thread that executes ClipboardTransferable.getClipboardFormats() is interrupted. This can be reproduced with the following test case: --------------------------------------------------------------------- import java.awt.Toolkit; import java.awt.datatransfer.*; public class Test { public static void main(String[] args) { final Object o = new Object(); final Runnable r = new Runnable() { public void run() { Clipboard clipboard = Toolkit.getDefaultToolkit().getSystemSelection(); synchronized (o) { o.notifyAll(); } Transferable t = clipboard.getContents(null); } }; final Thread t = new Thread(r); synchronized (o) { t.start(); try { o.wait(); } catch (InterruptedException ie) { ie.printStackTrace(); } } t.interrupt(); } } --------------------------------------------------------------------- The hang is reproducible with b87 on Linux, Sparc/Solaris and Intel/Solaris. Compile and run the test case. The test will hang. The thread dump at the point of hang looks as follows: Full thread dump Java HotSpot(TM) Client VM (1.4.0-rc-b87 mixed mode): "Thread-2" prio=5 tid=0x2bd40 nid=0x1 waiting on monitor [0..ffbee840] "AWT-Motif" daemon prio=6 tid=0x27e798 nid=0xd waiting for monitor entry [f1501000..f15019c8] at sun.awt.motif.MToolkit.run(Native Method) at java.lang.Thread.run(Thread.java:539) "Thread-1" prio=5 tid=0x14ec38 nid=0xb runnable [f1c81000..f1c819c8] at sun.awt.datatransfer.ClipboardTransferable.getClipboardFormats(Native Method) at sun.awt.datatransfer.ClipboardTransferable.<init>(ClipboardTransferable.java:67) at sun.awt.datatransfer.SunClipboard.getContents(SunClipboard.java:83) - locked <f20915f8> (a sun.awt.motif.X11Clipboard) at Test$1.run(Test.java:13) at java.lang.Thread.run(Thread.java:539) "Signal Dispatcher" daemon prio=10 tid=0xa78b0 nid=0x9 runnable [0..0] "Finalizer" daemon prio=8 tid=0xa1f50 nid=0x6 waiting on monitor [fa381000..fa3819c8] at java.lang.Object.wait(Native Method) - waiting on <f2210688> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:114) - locked <f2210688> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:130) at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:162) "Reference Handler" daemon prio=10 tid=0xa06e8 nid=0x5 waiting on monitor [fdf81000..fdf819c8] at java.lang.Object.wait(Native Method) - waiting on <f2210178> (a java.lang.ref.Reference$Lock) at java.lang.Object.wait(Object.java:429) at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116) - locked <f2210178> (a java.lang.ref.Reference$Lock) "VM Thread" prio=5 tid=0x9f410 nid=0x4 runnable "VM Periodic Task Thread" prio=10 tid=0xa66d0 nid=0x7 waiting on monitor "Suspend Checker Thread" prio=10 tid=0xa6fc0 nid=0x8 runnable ClipboardTransferable.getClipboardFormats() calls XtGetSelectionValue() that sends a request to get the set of targets supported by the selection owner. XtGetSelectionValue() registers a procedure that is called when the request is processed. After that it waits in a loop until the registered procedure is called on the toolkit thread. To wait it repeatedly calls JNI function MonitorWait() on the awt_lock object. When the calling thread is interrupted, MonitorWait() throws InterruptedException. This exception is not cleared, so all the following MonitorWait() calls in a loop will fail. The toolkit thread needs to acquire the awt_lock to call the registered procedure, since the calling thread never releases awt_lock ownership. So the calling thread is blocked in the loop forever. The problem is not reproducible when the type of execution is set to Internal Execution, since in this case the selection owner resides in the same process as Netbeans and the data transfer is performed entirely in Java without going to the native side. ###@###.### 2001-12-04 ====================================================================== Name: dsR10078 Date: 12/06/2001 On Solaris the test case in the evaluation above throws NoClassDefFoundError. java.lang.NoClassDefFoundError: sun/awt/datatransfer/ClipboardTransferable at sun.awt.datatransfer.SunClipboard.getContents(SunClipboard.java:83) at Test$1.run(Test.java:13) at java.lang.Thread.run(Thread.java:539) It is caused by the bug 4549130. The problem is that the class loader fails to load a class if the loading thread is interrupted. The following test case demonstrates the hang regardless of 4549130 is as follows: ------------------------------------------------------------------------------- import java.awt.Toolkit; import java.awt.datatransfer.Clipboard; public class HangTest { public static void main(String[] args) { Clipboard clipboard = Toolkit.getDefaultToolkit().getSystemSelection(); clipboard.getContents(null); Thread.currentThread().interrupt(); clipboard.getContents(null); } } ------------------------------------------------------------------------------- This test hangs in ClipboardTransferable.getClipboardFormats() with merlin b88 and completes successfully with the suggested fix. ###@###.### 2001-12-06 ======================================================================

SUGGESTED FIX Name: dsR10078 Date: 12/04/2001 Clear all exceptions thrown in MonitorWait() and break from the loop. We have to clear the exception for AWT_UNLOCK() to succeed. --- awt_MToolkit.c Tue Dec 4 18:42:49 2001 *************** *** 2004,2009 **** --- 2004,2013 ---- AWT_FLUSHOUTPUT_NOW(); while ((*terminateFn) (data) == 0) { AWT_WAIT(AWT_MAX_POLL_TIMEOUT); + if ((*env)->ExceptionCheck(env)) { + (*env)->ExceptionClear(env); + break; + } } AWT_NOTIFY_ALL(); AWT_UNLOCK(); ###@###.### 2001-12-04 ======================================================================