Java Solaris Communities Sun Store Join SDN My Profile Why Join?
 
Bug Database
Bug Detail
Quick Lists
Top 25 Bugs
Top 25 RFE's
Recently Closed Bugs
Printable Page Printable Page


Bug Database
Bug ID: 4818143
Votes 25
Synopsis NetBeans Hungs on sun.awt.datatransfer.ClipboardTransferable.getClipboardData
Category java:dragndrop
Reported Against 1.4.1
Release Fixed mustang(b40)
State 10-Fix Delivered, bug
Priority: 3-Medium
Related Bugs 6255835 , 6374355 , 6794763 , 6180249 , 4532299 , 4513976
Submit Date 13-FEB-2003
Description


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. customer .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) 
======================================================================




This behavior also occurs with Idea from JetBrains
(http://www.intellij.com/idea/).
(Review ID: 180308)
======================================================================
Work Around
N/A
Evaluation


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).

  xxxxx@xxxxx   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.
  xxxxx@xxxxx   2003-02-28




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.

  xxxxx@xxxxx    2004-03-02


======================================================================




NetBeans worked around the issue, so this bug isn't critical now.
See some useful parts of a discussion in the comments section.

  xxxxx@xxxxx    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.

======================================================================
  xxxxx@xxxxx   2005-05-20 10:58:08 GMT
Comments
  
  Include a link with my name & email   

Submitted On 17-FEB-2003
vanob
http://www.netbeans.org/servlets/ReadMsg?msgId=457153&listName=nbdev


Submitted On 03-JUL-2003
kovac
This also happens on JDK 1.4.2


Submitted On 18-JUL-2003
Tiny_Toon
I'm also affected by this bug. I come across it very often. :-(
JDK is 1.4.2-b28, Netbeans 3.5.
Linux 2.4.20 / SuSE 8.2


Submitted On 30-JUL-2003
dtropp
http://www.netbeans.org/issues/show_bug.cgi?id=34879
http://www.netbeans.org/issues/show_bug.cgi?id=30941

This is soooo annoying. Anytime I open my browser (Mozilla
Firebird) and highlight some text (ie. copy under linux)
with the netbeans source editor underneath it stops
responding. The links above have stack traces. The problem
seems to be with a lock for the clipboard. Hope it gets
fixed soon.


Submitted On 30-SEP-2003
Kovica
I think I found a workaround for this.
I'm using KDE 3.1.x and I have Klipper started.
Every time I want to use debugger (NB frooze when I wanted
to use debugger) I clear the clipboard history with Klipper.
Then it does work, but a bit slow.


Submitted On 31-MAR-2004
vanuatoo
How netbeans worked around the issue? Could you please more
specific?
What release will contain the fix? 3.6 is knocking on the door.


Submitted On 13-SEP-2004
cowwoc
The Netbeans workaround for this issue has serious bugs of its own causing major usability problems. For example: quite often you copy from a native components, try pasting into the editor but the *previous* contents of the clipboard get pasted. To get the correct clipboard contents to paste, you need to switch focus away from Netbeans back to the native app, and back a *second* time, *then* paste. Again this is a serious usability problem and seriously hampers productivity.

We need a JDK fix as soon as possible.


Submitted On 21-MAY-2005
vanuatoo
Any chance the fix will be incorporated in 1.5.x updates?


Submitted On 17-AUG-2005
cevaceva
will this fix be applied to jdk1.5?


Submitted On 05-OCT-2006
Jarek
I would really like this applied to JDK 1.5


Submitted On 30-OCT-2006
pischket
This bug is not fixed in Mustang.  It may work in the narrow context of Netbeans, but this bug is easily reproducible in build 100 of Mustang using the following steps.

 1. Copy any text from Abiword into clipboard
 2. Attempt to paste into any Java app
 3. HANG

This bug should be reopened.


Submitted On 31-OCT-2006
funkiwan
I'm still seeing this issue as well. I'm using IntelliJ 6.0.1 (a Java IDE) and just received this message in a warning dialog after attempting to copy something:

-- snip --
You're seeing this message because of the workaround to JRE issue: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4818143
IDEA would hang otherwise. The system clipboard might be not working correctly. It is recommended to restart IDEA.
-- snip --

My jdk:
java version "1.5.0_09"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_09-b01)
Java HotSpot(TM) Client VM (build 1.5.0_09-b01, mixed mode, sharing)

My platform:
Linux kubuntu 2.6.15-23-386 #1 PREEMPT Tue May 23 13:49:40 UTC 2006 i686 GNU/Linux


Submitted On 21-NOV-2006
jaygindin
I'm seeing the same message as the previous poster rather frequently when running in IntelliJ 6.0.2 on Linux. Basically, from that point on, the clipboard is hosed, and the ony work-around is to restart IntelliJ.

Please re-open this and fix it.


Submitted On 11-JAN-2007
Reproduced with IntelliJ IDEA 6.0.2 (build #6107), 
java version "1.6.0"
Java(TM) SE Runtime Environment (build 1.6.0-b105)
Java HotSpot(TM) Server VM (build 1.6.0-b105, mixed mode)

Linux foo 2.6.15-27-686 #1 SMP PREEMPT Fri Dec 8 18:00:07 UTC 2006 i686 GNU/Linux


Submitted On 31-JAN-2008
erasmus
Reproduced this bug:

OS: OpenSUSE 10.3
Software used to reproduce bug: IntelliJ Idea 7.0.2
Using JDK:

java version "1.6.0_03"
Java(TM) SE Runtime Environment (build 1.6.0_03-b05)
Java HotSpot(TM) 64-Bit Server VM (build 1.6.0_03-b05, mixed mode)

Way to reproduce: simply create an empty project and copy-paste some code in any source file.

Please reopen. Bug is definitely NOT FIXED!


Submitted On 17-FEB-2008
The problem persists with Idea 6.x, 7.x on FreeBSD 6.x, too.


Submitted On 23-APR-2009
Confirming NOT fixed. Persists on Linux i386 with Idea 8.01 using JDK 1.6.0_07 when using clipboard.


Submitted On 04-AUG-2009
rocketraman
Continues on Linux x86_64 2.6.27.25 (Fedora 10) with IntelliJ 8.1.2, JDK 1.6.0_14.


Submitted On 21-SEP-2009
Zeemvel
I have this bug with IntelliJ. I'm running Ubuntu 9.04. If IntelliJ is running, and I use "print screen" and then use "copy to clipboard" in the dialog that Gnome then shows, then IntelliJ shows a message with the URL to this bug in it, and the clipboard stops working in IntelliJ, I have to restart IntelliJ 2 or 3 times before it works again. This is very annoying, and already since 2003? Please fix it.



PLEASE NOTE: JDK6 is formerly known as Project Mustang