Bug 201775 - Deadlock when starting IDE with previously opened java file
Deadlock when starting IDE with previously opened java file
Status: RESOLVED FIXED
Product: debugger
Classification: Unclassified
Component: Code
7.1
PC Linux
: P1 (vote)
: 7.1
Assigned To: Martin Entlicher
issues@debugger
: REGRESSION, THREAD
: 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
:


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

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(Object.java:485)
	at org.openide.text.CloneableEditor$DoInitialize.initDocument(CloneableEditor.java:708)
	at org.openide.text.CloneableEditor$DoInitialize.initVisual(CloneableEditor.java:746)
	at org.openide.text.CloneableEditor.getEditorPane(CloneableEditor.java:1279)
	at org.netbeans.core.multiview.MultiViewCloneableTopComponent.getEditorPane(MultiViewCloneableTopComponent.java:241)
	at org.openide.text.CloneableEditorSupport.getRecentPane(CloneableEditorSupport.java:1202)
	at org.openide.text.NbDocument.findRecentEditorPane(NbDocument.java:398)
	at org.netbeans.spi.debugger.ui.EditorContextDispatcher$EditorLookupListener.updateCurrentOpenedPane(EditorContextDispatcher.java:660)
	at org.netbeans.spi.debugger.ui.EditorContextDispatcher$EditorLookupListener.access$300(EditorContextDispatcher.java:533)
	at org.netbeans.spi.debugger.ui.EditorContextDispatcher$EditorLookupListener$1.run(EditorContextDispatcher.java:605)
	at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)

and resulting in: http://statistics.netbeans.org/exceptions/exception.do?id=526819
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 {
  NbDocument.findRecentEditorPane(ec)
}
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
http://hg.netbeans.org/main/rev/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'
Changeset: http://hg.netbeans.org/main-golden/rev/033e6742d23f
User: mentlicher@netbeans.org
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,

{
   // ...
}

suffices.
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. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo