United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-4818143 NetBeans Hungs on sun.awt.datatransfer.ClipboardTransferable.getClipboardData
JDK-4818143 : NetBeans Hungs on sun.awt.datatransfer.ClipboardTransferable.getClipboardData

Details
Type:
Bug
Submit Date:
2003-02-13
Status:
Resolved
Updated Date:
2005-11-21
Project Name:
JDK
Resolved Date:
2005-06-05
Component:
client-libs
OS:
linux
Sub-Component:
java.awt
CPU:
x86
Priority:
P3
Resolution:
Fixed
Affected Versions:
1.4.1
Fixed Versions:

Related Reports
Relates:
Relates:
Relates:
Relates:
Relates:
Relates:

Sub Tasks

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
CONVERTED DATA

BugTraq+ Release Management Values

COMMIT TO FIX:
mustang


                                     
2004-09-26
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
                                     
2005-05-20



Hardware and Software, Engineered to Work Together