Please use the Apache issue tracking system for new NetBeans issues ( !!
Bug 201775 - Deadlock when starting IDE with previously opened java file
Deadlock when starting IDE with previously opened java file
Product: debugger
Classification: Unclassified
Component: Code
PC Linux
: P1 (vote)
: 7.1
Assigned To: Martin Entlicher
: 201810 201813 201898 (view as bug list)
Depends on:
Blocks: 186117
  Show dependency treegraph
Reported: 2011-09-07 19:31 UTC by Miloslav Metelka
Modified: 2011-09-18 10:29 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT

Thread dump of deadlock (18.89 KB, text/plain)
2011-09-07 19:31 UTC, Miloslav Metelka

Note You need to log in before you can comment on or make changes to this bug.
Description Miloslav Metelka 2011-09-07 19:31:17 UTC
Created attachment 110500 [details]
Thread dump of deadlock

NetBeans IDE Dev (Build 20110907-6421954e36ec) (#6421954e36ec)
Linux version 2.6.38-11-generic running on amd64
1.6.0_25; Java HotSpot(TM) 64-Bit Server VM 20.0-b11; Sun Microsystems Inc.
on Ubuntu 11.04

When restarting IDE which was shutdown with a java file opened I've got deadlock of document opening <-> EditorContextDispatcher.
Comment 1 Martin Entlicher 2011-09-08 09:31:32 UTC
IMHO you should not call java.lang.Object.wait() in AWT thread, since it can not be guaranteed how long it will take till it's notified...
Comment 2 Martin Entlicher 2011-09-08 12:42:32 UTC
*** Bug 201813 has been marked as a duplicate of this bug. ***
Comment 3 Martin Entlicher 2011-09-08 12:45:07 UTC
*** Bug 201810 has been marked as a duplicate of this bug. ***
Comment 4 Jesse Glick 2011-09-08 12:45:43 UTC
Happened again on next startup. Could recover IDE by trying to open it again from the shell, thus triggering recovery via CLI:

org.netbeans.core.CLIOptions2$EQStuck: GUI is not responsive
	at java.lang.Object.wait(Native Method)
	at java.lang.Object.wait(
	at org.openide.text.CloneableEditor$DoInitialize.initDocument(
	at org.openide.text.CloneableEditor$DoInitialize.initVisual(
	at org.openide.text.CloneableEditor.getEditorPane(
	at org.netbeans.core.multiview.MultiViewCloneableTopComponent.getEditorPane(
	at org.openide.text.CloneableEditorSupport.getRecentPane(
	at org.openide.text.NbDocument.findRecentEditorPane(
	at org.netbeans.spi.debugger.ui.EditorContextDispatcher$EditorLookupListener.updateCurrentOpenedPane(
	at org.netbeans.spi.debugger.ui.EditorContextDispatcher$EditorLookupListener.access$300(
	at org.netbeans.spi.debugger.ui.EditorContextDispatcher$EditorLookupListener$
	at java.awt.event.InvocationEvent.dispatch(

and resulting in:
Comment 5 Jesse Glick 2011-09-08 12:48:09 UTC
Looks like this will need a hotfix, so please consider committing with the parent set to the cause of the regression (i.e. update to the changeset of the cause) - this will make it easier for people to pull the hotfix directly into team repos without pulling unrelated and untested baggage.
Comment 6 Martin Entlicher 2011-09-08 13:15:19 UTC
I'm not aware of what has caused the regression, therefore I can not commit the fix to the correct parent.
The code in debugger did not change for a long time.

Milo, I call NbDocument.findRecentEditorPane(ec) only on EditorCookies that have already a document (I test for ec.getDocument() == null).
The condition is:
if (ec.getDocument() == null && (ec instanceof EditorCookie.Observable)) {
  // nothing
} else {
Therefore I'm surprised that it tries to initialize the document.
Isn't there some regression?

Also issue #186117 suggests that it's really not a good idea to call Object.wait() in AWT.
Comment 7 Martin Entlicher 2011-09-08 13:48:40 UTC
Fixed on debugger side by changeset:   201304:033e6742d23f
Comment 8 Miloslav Metelka 2011-09-09 12:40:41 UTC
There were no changes in openide.text and editor either. I guess what might be related are some changes in core.multiview.
Comment 9 Quality Engineering 2011-09-09 15:01:20 UTC
Integrated into 'main-golden'
Log: #201775 Prevent from deadlock, do not call NbDocument.findRecentEditorPane() in a synchronized block.
Comment 10 Jesse Glick 2011-09-09 16:20:02 UTC
BTW what is the point of

do {
   // ...
} while (false);

? If you just want an arbitrary block scope,

   // ...

Comment 11 Martin Entlicher 2011-09-18 10:29:26 UTC
> BTW what is the point of
> do {
>    // ...
> } while (false);

I'm using continue inside.
Comment 12 Martin Entlicher 2011-09-18 10:29:53 UTC
*** Bug 201898 has been marked as a duplicate of this bug. ***

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo