This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Dev Build 200402261900 Next amazing deadlock. I've worked in IDE than I switched to another application (mozilla), close it and return to IDE. There I tried to close an editor tab and IDE was blocked (data was lost). If I remember I didn't use clipboard between IDE and other applications.
Created attachment 13774 [details] Threads dump.
had you used debugger before the deadlock happened? Also see JDK bug 4818143. You also forgot to meantion OS platform and JDK version
I forgot to notice I didn't use debugger in that IDE run. And in threaddump made immediately after the deadlock the 'AWT-EventQueue-1' thread was still running but CPU was not used (to 5%). Here I've attached next threaddump. JDK 1.4.2_03, RadHat 9 Gnome 2.2
this is a confirmed bug in AWT http://developer.java.sun.com/developer/bugParade/bugs/4818143.html We can't do anything about it in our code base. See also issue 40346, a different manifestation of the same AWT bug.
I am reopening this bug, have a workaround prepared, will commit shortly
Created attachment 13820 [details] NBClipboard part of the workaround
Reliable steps to reproduce the hang on Unix: 1) run any app on X (say mozilla, or JDK Notepad java demo) from the console 2) in that app, select some text, copy it into the clipboard 3) switch to the console, press Ctrl-Z to suspend the app 4) switch to the IDE, it will hangs 5) if not (after nbclipboard hack attached) pressing Ctrl+V in the NB editor will cause the IDE to hang Issue 40346, debugging the app which owns the clipboard, is only a special case of how the clipboard owner is suspended
my fix in NbClipboard: i call into the system clipboard from a separate thread, in the worst case only that thread will hang, not the whole IDE. After that point the IDE will ignore the system clipboard completely, no copy/paste b/w the IDE and the external app is possible. It's the best we can achieve
Created attachment 13822 [details] This patch convinces all Swing text components to use ExClipboard instead of Toolkit.getSystemClipboard, works on 1.4 and 1.5beta, test is not finished yet
fixed in trunk
Created attachment 13824 [details] my and yarda's combined patch against release36
patch against release36 to work around the AWT bug attached. yarda and i reviewed each other's patch. consider this reviewed. We also tested all the scenerios we know how to hang the IDE and how clipboard is used in the IDE. Appreciate if someone from QA can verify independently
*** Issue 40346 has been marked as a duplicate of this issue. ***
the fix seems to trigger bug 40785
Eman, could you verify in trunk , thanks in advance. (I am sorry but I can't reproduce it in NB3.6)
Created attachment 13858 [details] Enhanced patch to also address issue 40785
Created attachment 13866 [details] Additional fix of issue 40820
Verified in 200403071900.
Backported to 3.6: /cvs/openide/src/org/openide/util/datatransfer/ExTransferable.java,v <-- ExTransferable.java new revision: 1.19.118.1; previous revision: 1.19 done Processing log script arguments... More commits to come... Checking in core/bootstrap/src/org/netbeans/TopSecurityManager.java; /cvs/core/bootstrap/src/org/netbeans/TopSecurityManager.java,v <-- TopSecurityManager.java new revision: 1.6.52.1; previous revision: 1.6 done Processing log script arguments... More commits to come... Checking in core/src/org/netbeans/core/NbClipboard.java; /cvs/core/src/org/netbeans/core/NbClipboard.java,v <-- NbClipboard.java new revision: 1.13.2.1; previous revision: 1.13 done Checking in core/src/org/netbeans/core/NonGui.java; /cvs/core/src/org/netbeans/core/NonGui.java,v <-- NonGui.java new revision: 1.103.4.1; previous revision: 1.103