JDK-4818143 : NetBeans Hungs on sun.awt.datatransfer.ClipboardTransferable.getClipboardData
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 1.4.1
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux
  • CPU: x86
  • Submitted: 2003-02-13
  • Updated: 2017-05-19
  • Resolved: 2005-06-05
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.
JDK 6
6 b40Fixed
Related Reports
Relates :  
JDK-6180249 - DataTransfer of animated GIF through system clipboard throws IOException on XToolkit (inter-JVM)
Relates :  
JDK-6255835 - TransferHandler.pasteAction should not use Clipboard.getContents() for performance reasons
Relates :  
JDK-6374355 - FlavorEvent should provide DataFlavors
Relates :  
JDK-4532299 - Neverending loop in sun.awt.datatransfer.SunClipboard.getContents
Relates :  
JDK-4513976 - DnDImageTest failing for between JVM scenario on Solaris 64-bit
Relates :  
JDK-6794763 - Unexpected behavior of a "copy/paste" operation with some external editors
Description
Name: rl43681			Date: 02/13/2003


FULL PRODUCT VERSION :
java -version
java version "1.4.1_01"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_01-b01)
Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode)

FULL OPERATING SYSTEM VERSION :
Linux vanob_rh 2.4.18-24.8.0 #1 Fri Jan 31 07:28:55 EST 2003
i686 athlon i386 GNU/Linux
glibc-2.2.93-5
ADDITIONAL OPERATING SYSTEMS :
Redhat 80

EXTRA RELEVANT SYSTEM CONFIGURATION :
AMD Athlon XP 1800+
512MB RAM
GeForce2 MX400 32MB


A DESCRIPTION OF THE PROBLEM :
I was working in the NetBeans IDE 3.4.1
I switched to another window and some times later back to
the ide that had been hung. I filled a bug
http://www.netbeans.org/issues/show_bug.cgi?id=30941
to NetBeans bugzilla and they told me that was a jdk bug.

Providing full thread dump

EXPECTED VERSUS ACTUAL BEHAVIOR :
When IDE is hung you may loose lot of work, because the only
method is to kill the process.

ERROR MESSAGES/STACK TRACES THAT OCCUR :
Full Thread dump:

Full thread dump Java HotSpot(TM) Client VM
(1.4.1_01-b01 mixed mode):

"Inactive RequestProcessor thread" daemon prio=1
tid=0x0x84fa000 nid=0x3367 in O
bject.wait() [53101000..53101830]
        at java.lang.Object.wait(Native Method)
        at
org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java
:574)
        - locked <0x446d00c0> (a java.lang.Object)

"Inactive RequestProcessor thread" daemon prio=1
tid=0x0x84fa350 nid=0x3226 in O
bject.wait() [52e91000..52e91830]
        at java.lang.Object.wait(Native Method)
        at
org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java
:574)
        - locked <0x46b0a338> (a java.lang.Object)

"Compilation" daemon prio=1 tid=0x0x877f2e0
nid=0x3199 in Object.wait() [53dea00
0..53dea830]
        at java.lang.Object.wait(Native Method)
        - waiting on <0x45fa9498> (a
java.util.LinkedList)
        at java.lang.Object.wait(Object.java:426)
        at
org.netbeans.core.compiler.CompilationEngineImpl$CompilerThread.nextJ
obAndTask(CompilationEngineImpl.java:172)
        - locked <0x45fa9498> (a java.util.LinkedList)
        at
org.netbeans.core.compiler.CompilationEngineImpl$CompilerThread.run(C
ompilationEngineImpl.java:185)

"Debugger Request Processor" daemon prio=1
tid=0x0x83bad40 nid=0x3183 in Object.
wait() [53cbc000..53cbc830]
        at java.lang.Object.wait(Native Method)
        - waiting on <0x45e37aa0> (a
java.util.TreeSet)
        at
org.netbeans.modules.debugger.support.util.RequestProcessor$Processor
Thread.run(RequestProcessor.java:526)
        - locked <0x45e37aa0> (a java.util.TreeSet)

"Debugger operator thread" prio=1 tid=0x0x52f0ede8
nid=0x3182 in Object.wait() [
53fee000..53fee830]
        at java.lang.Object.wait(Native Method)
        - waiting on <0x45d60728> (a
com.sun.tools.jdi.EventQueueImpl)
        at java.lang.Object.wait(Object.java:426)
        at
com.sun.tools.jdi.EventQueueImpl.removeUnfiltered(EventQueueImpl.java
:162)
        - locked <0x45d60728> (a
com.sun.tools.jdi.EventQueueImpl)
        at
com.sun.tools.jdi.EventQueueImpl.remove(EventQueueImpl.java:78)
        at
com.sun.tools.jdi.EventQueueImpl.remove(EventQueueImpl.java:64)
        at
org.netbeans.modules.debugger.jpda.util.Operator$1.run(Operator.java:
73)
        at java.lang.Thread.run(Thread.java:536)

"JDI Target VM Interface" daemon prio=1
tid=0x0x52f0e150 nid=0x3181 runnable [53
f6d000..53f6d830]
        at
java.net.SocketInputStream.socketRead0(Native Method)
        at
java.net.SocketInputStream.read(SocketInputStream.java:129)
        at
java.io.BufferedInputStream.fill(BufferedInputStream.java:183)
        at
java.io.BufferedInputStream.read(BufferedInputStream.java:201)
        - locked <0x45d1ec48> (a
java.io.BufferedInputStream)
        at
com.sun.tools.jdi.SocketConnection.receivePacket(SocketConnection.jav
a:58)
        - locked <0x45d1ec68> (a java.lang.Object)
        at
com.sun.tools.jdi.TargetVM.run(TargetVM.java:96)
        at java.lang.Thread.run(Thread.java:536)

"JDI Internal Event Handler" daemon prio=1
tid=0x0x52f0ddd0 nid=0x3.wait() [53eec000..53eec830]
        at java.lang.Object.wait(Native Method)
        - waiting on <0x45d607a0> (a
com.sun.tools.jdi.EventQueueImpl)
        at java.lang.Object.wait(Object.java:426)
        at
com.sun.tools.jdi.EventQueueImpl.removeUnfiltered(EventQueueImpl.java
:162)
        - locked <0x45d607a0> (a
com.sun.tools.jdi.EventQueueImpl)
        at
com.sun.tools.jdi.EventQueueImpl.removeInternal(EventQueueImpl.java:9
7)
        at
com.sun.tools.jdi.InternalEventHandler.run(InternalEventHandler.java:
36)
        at java.lang.Thread.run(Thread.java:536)

"Compilation" daemon prio=1 tid=0x0x80cd3f0
nid=0x30c1 in Object.wait() [5308000
0..53080830]
        at java.lang.Object.wait(Native Method)
        - waiting on <0x45ac3970> (a
java.util.LinkedList)
        at java.lang.Object.wait(Object.java:426)
        at
org.netbeans.core.compiler.CompilationEngineImpl$CompilerThread.nextJ
obAndTask(CompilationEngineImpl.java:172)
        - locked <0x45ac3970> (a java.util.LinkedList)
        at
org.netbeans.core.compiler.CompilationEngineImpl$CompilerThread.run(C
ompilationEngineImpl.java:185)

"AntProjectSupport.FiringProcessor" daemon prio=1
tid=0x0x828ff50 nid=0x30ba in
Object.wait() [4f314000..4f314830]
        at java.lang.Object.wait(Native Method)
        - waiting on <0x451fb1b8> (a
java.util.HashMap)
        at
org.apache.tools.ant.module.xml.AntProjectSupport$FiringProcessor.run
(AntProjectSupport.java:618)
        - locked <0x451fb1b8> (a java.util.HashMap)

"Thread-5" prio=1 tid=0x0x84601a0 nid=0x30af
runnable [50289000..50289830]
        at
java.net.PlainSocketImpl.socketAccept(Native Method)
        at
java.net.PlainSocketImpl.accept(PlainSocketImpl.java:353)
        - locked <0x44fe54c8> (a
java.net.PlainSocketImpl)
        at
java.net.ServerSocket.implAccept(ServerSocket.java:439)
        at
java.net.ServerSocket.accept(ServerSocket.java:410)
        at
org.netbeans.modules.web.monitor.client.PortServer.run(PortServer.jav
a:67)

"TimerQueue" daemon prio=1 tid=0x0x86f0108
nid=0x30ac in Object.wait() [52e10000
..52e10830]
        at java.lang.Object.wait(Native Method)
        - waiting on <0x44e06798> (a
javax.swing.TimerQueue)
        at
javax.swing.TimerQueue.run(TimerQueue.java:231)
        - locked <0x44e06798> (a
javax.swing.TimerQueue)
        at java.lang.Thread.run(Thread.java:536)

"Thread-4" daemon prio=1 tid=0x0x85eb8b8
nid=0x30ab in Object.wait() [50584000..
50584830]
        at java.lang.Object.wait(Native Method)
        - waiting on <0x44cf6870> (a
org.netbeans.core.modules.ChangeFirer)
        at java.lang.Object.wait(Object.java:426)
        at
org.netbeans.core.modules.ChangeFirer.run(ChangeFirer.java:94)
        - locked <0x44cf6870> (a
org.netbeans.core.modules.ChangeFirer)

"Thread-3" daemon prio=1 tid=0x0x854b618
nid=0x30aa in Object.wait() [5048d000..
5048d830]
        at java.lang.Object.wait(Native Method)180
in Object
 at java.util.TimerThread.mainLoop(Timer.java:429)
        - locked <0x44c31bb8> (a java.util.TaskQueue)
        at java.util.TimerThread.run(Timer.java:382)

"AWT-EventQueue-0" prio=1 tid=0x0x8545b58
nid=0x30a9 in Object.wait() [5040b000.
.5040c830]
        at java.lang.Object.wait(Native Method)
        - waiting on <0x4a623210> (a java.lang.Class)
        at
sun.awt.datatransfer.ClipboardTransferable.getClipboardData(Native
Me
thod)
        at
sun.awt.datatransfer.ClipboardTransferable.fetchOneFlavor(ClipboardTr
ansferable.java:106)
        at
sun.awt.datatransfer.ClipboardTransferable.<init>(ClipboardTransferab
le.java:80)
        at
sun.awt.datatransfer.SunClipboard.getContents(SunClipboard.java:80)
        - locked <0x45269530> (a
sun.awt.motif.X11Clipboard)
        at
org.netbeans.core.NbClipboard.eventDispatched(NbClipboard.java:117)
        at
java.awt.Toolkit$SelectiveAWTEventListener.eventDispatched(Toolkit.ja
va:2118)
        at
java.awt.Toolkit$ToolkitEventMulticaster.eventDispatched(Toolkit.java
:2012)
        at
java.awt.Toolkit$ToolkitEventMulticaster.eventDispatched(Toolkit.java
:2011)
        at
java.awt.Toolkit$ToolkitEventMulticaster.eventDispatched(Toolkit.java
:2011)
        at
java.awt.Toolkit$ToolkitEventMulticaster.eventDispatched(Toolkit.java
:2011)
        at
java.awt.Toolkit$ToolkitEventMulticaster.eventDispatched(Toolkit.java
:2011)
        at
java.awt.Toolkit$ToolkitEventMulticaster.eventDispatched(Toolkit.java
:2011)
        at
java.awt.Toolkit.notifyAWTEventListeners(Toolkit.java:1970)
        at
java.awt.Component.dispatchEventImpl(Component.java:3513)
        at
java.awt.Container.dispatchEventImpl(Container.java:1623)
        at
java.awt.Window.dispatchEventImpl(Window.java:1585)
        at
java.awt.Component.dispatchEvent(Component.java:3439)
        at
java.awt.KeyboardFocusManager.redispatchEvent(KeyboardFocusManager.ja
va:1688)
        at
java.awt.DefaultKeyboardFocusManager.typeAheadAssertions(DefaultKeybo
ardFocusManager.java:734)
        at
java.awt.DefaultKeyboardFocusManager.dispatchEvent(DefaultKeyboardFoc
usManager.java:340)
        at
java.awt.Component.dispatchEventImpl(Component.java:3468)
        at
java.awt.Container.dispatchEventImpl(Container.java:1623)
        at
java.awt.Window.dispatchEventImpl(Window.java:1585)
        at
java.awt.Component.dispatchEvent(Component.java:3439)
        at
java.awt.EventQueue.dispatchEvent(EventQueue.java:450)
        at
java.awt.SentEvent.dispatch(SentEvent.java:50)
        at
java.awt.DefaultKeyboardFocusManager$DefaultKeyboardFocusManagerSentE
vent.dispatch(DefaultKeyboardFocusManager.java:143)
        at
java.awt.DefaultKeyboardFocusManager.sendMessage(DefaultKeyboardFocus
Manager.java:169)
        at
java.awt.DefaultKeyboardFocusManager.dispatchEvent(DefaultKeyboardFoc
usManager.java:245)
        at
java.awt.Component.dispatchEventImpl(Component.java:3468)
        at
java.awt.Container.dispatchEventImpl(Container.java:1623)
        at
java.awt.Window.dispatchEventImpl(Window.java:1585)
        at
java.awt.Component.dispatchEvent(Component.java:3439)
        at
java.awt.EventQueue.dispatchEvent(EventQueue.java:450)
        at
java.awt.SequencedEvent.dispatch(SequencedEvent.java:91)
 at
java.awt.EventQueue.dispatchEvent(EventQueue.java:448)
        at
java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchTh
read.java:197)
        at
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThre
ad.java:150)
        at
java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:144)
        at
java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:136)
        at
java.awt.EventDispatchThread.run(EventDispatchThread.java:99)

"Thread-1" daemon prio=1 tid=0x0x84fb5e0
nid=0x30a8 in Object.wait() [5038b000..
5038b830]
        at java.lang.Object.wait(Native Method)
        at
java.util.TimerThread.mainLoop(Timer.java:429)
        - locked <0x44c31cb0> (a java.util.TaskQueue)
        at java.util.TimerThread.run(Timer.java:382)

"Java2D Disposer" daemon prio=1 tid=0x0x851df90
nid=0x30a7 in Object.wait() [503
0a000..5030a830]
        at java.lang.Object.wait(Native Method)
        at
java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:111)
        - locked <0x44c31d30> (a
java.lang.ref.ReferenceQueue$Lock)
        at
java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:127)
        at sun.java2d.Disposer.run(Disposer.java:97)
        at java.lang.Thread.run(Thread.java:536)

"AWT-Motif" daemon prio=1 tid=0x0x851a4f0
nid=0x30a5 runnable [50208000..5020883
0]
        at sun.awt.motif.MToolkit.run(Native Method)
        at java.lang.Thread.run(Thread.java:536)

"AWT-Shutdown" prio=1 tid=0x0x84e3e88 nid=0x30a4
in Object.wait() [50169000..501
69830]
        at java.lang.Object.wait(Native Method)
        - waiting on <0x44bf04b0> (a java.lang.Object)
        at java.lang.Object.wait(Object.java:426)
        at
sun.awt.AWTAutoShutdown.run(AWTAutoShutdown.java:259)
        - locked <0x44bf04b0> (a java.lang.Object)
        at java.lang.Thread.run(Thread.java:536)

"DestroyJavaVM" prio=1 tid=0x0x8052438 nid=0x309a
waiting on condition [0..bfffb
710]

"Signal Dispatcher" daemon prio=1 tid=0x0x80a4cf0
nid=0x30a1 waiting on conditio
n [0..0]

"Finalizer" daemon prio=1 tid=0x0x8087bf8
nid=0x309e in Object.wait() [4e470000.
.4e470830]
        at java.lang.Object.wait(Native Method)
        at
java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:111)
        - locked <0x44b9d5e0> (a
java.lang.ref.ReferenceQueue$Lock)
        at
java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:127)
        at
java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159)

"Reference Handler" daemon prio=1 tid=0x0x8086100
nid=0x309d in Object.wait() [4
1fab000..41fab830]
        at java.lang.Object.wait(Native Method)
        at java.lang.Object.wait(Object.java:426)
        at
java.lang.ref.Reference$ReferenceHandler.run(Reference.java:113)
        - locked <0x44b9d4c0> (a
java.lang.ref.Reference$Lock)
"VM Thread" prio=1 tid=0x0x8082ee8 nid=0x309c
runnable

"VM Periodic Task Thread" prio=1 tid=0x0x80a3938
nid=0x309f waiting on condition
 
"Suspend Checker Thread" prio=1 tid=0x0x80a42a0
nid=0x30a0 runnable

REPRODUCIBILITY :
This bug can be reproduced often.
(Review ID: 181123) 
======================================================================

Name: jl125535			Date: 08/04/2003


This behavior also occurs with Idea from JetBrains
(http://www.intellij.com/idea/).
(Review ID: 180308)
======================================================================
Comments
EVALUATION Name: dsR10078 Date: 02/17/2003 I couldn't reproduce the problem with NetBeans 3.4.1 and JDK 1.4.1. Since the steps to reproduce the problem are not documented in the bug description, we can only guess the actual cause of the hang. On X11 systems, if the current clipboard owner resides in another application, ClipboardTransferable.getClipboardData() sends a SelectionRequest to the owner and waits for response. The hang can happen if the owner never responds to the request for whatever reason (crash, hang or other malfunction). ###@###.### 2003-02-17 ====================================================================== The bug can easily be reproduced in a simple Swing app without using NetBeans. Read http://www.netbeans.org/servlets/ReadMsg?msgId=457153&listName=nbdev and specifically point #4. In sum: copy several hundred Kb of data from an Emacs buffer using X clipboard copy mode, then attempt to get the clipboard contents from a Java app. The Java app freezes at once. I tend to agree that the ultimate problem is not really in Java but in whatever app made the bad paste - Emacs, I think. However the fact remains that the AWT event thread is blocked and there is no recovery strategy in the JRE. For example, in my message I wrote that gEdit (a native app) also has problems retrieving the same paste - but it does not cause the app to hang, it just makes the paste fail. I.e. this is a robustness issue. I don't think it's good if any Java app which uses the clipboard can be suddenly frozen with no hope of recovery due to bugs in another app. Suggest perhaps that the Motif toolkit's clipboard handler try to access the X clipboard using either a separate thread or a watchdog timer that would let it recover from a defective clipboard event in a reasonable amount of time (say 30 seconds). It does not seem feasible to work around this bug in NetBeans code, as I wrote in my mailing list message. We could make *most* app clipboard accesses go through some special handling code which would try to call java.awt.Clipboard only in a special thread, which could not block the AWT thread. (It does not seem to be clearly documented whether you have to call data transfer methods from the AWT thread, as for GUI components - does it matter? Is data transfer independently synchronized, or does it rely on a single-threaded access mode?) However there are some kinds of code, e.g. JTextComponent, which will directly access the un-hacked-around system clipboard anyway, and there is no public API or even stable-looking hack to force them to use a special clipboard. I have only heard of this bug existing on Linux machines, though in principle it might also exist on Solaris. ###@###.### 2003-02-28 Name: agR10216 Date: 03/02/2004 NetBeans team discovered another scenario in which the bug reproduces: "The user is using the IDE to debug a java app, let's call it Notepad. In Notepad which is running under the debugger, the user selects some text and puts it in the system clipboard. Later on Notepad is suspended at a breakpoint. The user switches back to the IDE which asks the system clipboard for its contents (to determine if the Paste action should be enabled, or just because the user hits Ctrl+V). AWT passes the query to Notepad, the owner of the clipboard, which being suspended of course cannot answer. We have a reliably reproducible deadlock. ... This is a serious problem for us, close to be called showstopper..." Introduction of a system property that specifies a timeout which Clipboard.getContents() waits for "the owner of the clipboard"'s reply was proposed. ###@###.### 2004-03-02 ====================================================================== Name: agR10216 Date: 03/30/2004 NetBeans worked around the issue, so this bug isn't critical now. See some useful parts of a discussion in the comments section. ###@###.### 2004-03-30 ====================================================================== Refer to http://jplan.sfbay/feature/236, http://ccc.sfbay/4818143 and the comments section of this CR for plans concerning this feature. --------------------------- Problem Currently if a Java application requests for clipboard data on an X platform, then the thread which this request has been performed on waits for a response of the clipboard owner: it should provide the data requested or report that the data are unavailable. A malfunctioning clipboard owner may not answer so that the thread may wait indefinitely. This issue is especially annoying in GUI applications if a request for clipboard data is performed on the thread responsible for processing events, painting; in such a case a GUI application freezes. This problem is known to be reproducible only on X platforms, and initially it was reported against MAWT since the timeout, which the requestor waits for the data, is ULONG_MAX (practically the requestor waits for ever). XAWT has the timeout set to 10000ms, so that the requestor does not wait indefinitely. Such a timeout appeared to be sufficient even for large data transfers (there are no known issues with such a timeout). ----------------------------------- I proposed 3 kinds of API and discussed them with Swing and Netbeans representatives. 1. Asynchronous API for retrieval of data from the clipboard, i.e. a listener is registered, and it will be called when the clipboard contents is retrieved. Swing rejected this API mainly since it's hard for Swing to adapt to the API. 2. API that allow the following: while (! clipboard contents is retrieved) { if (waiting too long) { inform (or ask) a user; break waiting (or continue waiting); } wait(some_timeout); } if (clipboard contents is retrieved) { make use of the contents; } Also convenience methods, which wrap similar code, could be provided. Swing rejected the API mainly because of its complexity. 3. Timeout-based API was approved by Swing and Netbeans. After negotiations with Netbeans and Swing team representatives it was decided to implement a timeout-based API. Since such an API is rather low-level, and it isn't cross-platform, it should be private. Thus the solution is to introduce a system property which specifies the timeout in milliseconds, set the default timeout in MAWT to 10000ms as in XAWT (and put actions on the expiry of the timeout to rights in both XAWT and MAWT). After the solution was implemented, Netbeans decided that they need not the system property, so the appied solution is the same except for introduction of the system property. ====================================================================== ###@###.### 2005-05-20 10:58:08 GMT
20-05-2005
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mustang
26-09-2004