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.
[nb new winsys](031104), [jdk1.4.2_02] I cannot reproduce it again, but I have opened 5 xml files and than doubleclick on another xml node in Filesystems window and deadlock happends (see attached full thread-dump)
Created attachment 12067 [details] full thread-dump
at java.lang.Object.wait(Native Method) - waiting on <0xf0977590> (a org.openide.windows.CloneableOpenSupport$Listener) Does it wait for some dead thread?
It is a lock in CloneableEditorSupport.
Seems like the notification branch haven't got executed. I was thinking about missed notification, but this shouldn't be the case, as both wait and notifyAll are in enough-covering synchronized sections.
Yes, it seems the AWT thread was not properly notified and it's still waiting. Were there any other interesting conditions e.g. any exceptions thrown etc. Could you please attach the ide.log?
How can it happen the notify() is not called (thinking outloud)? Possibilities: A) Load task not started because: A1) status==DOC_NO, but prepTask != null A2) exception in prepareDocument (e.g. in createEditorKit) A3) bug in RP B) Load task started but didn't notified because: B1) status changed to DOC_NO (fast close) between open and run B2) document reference changed (more loads at once???) B3) Runtime exception during previous run() B3, because of the finally clause of the runnable will cause A1 on the next attempt, I think. B1 can be caused by the fix of issue #37432, but the fix was integrated after this bug. Weren't there really no exceptions?
We should nail the editor document handling issues for 3.6
OK, I've managed to get the IDE to very similar state (infinite waiting, but one level deeper in stack) just by OOME (or any other non-java.lang.RuntimeException) during loading. I believe that by fixing the state machine to handle correctly my test case, it will solve this problem as well. I'll keep working on it.
No you will not, I'll try it.
I think that after an hour I am able to reproduce the deadlock or something very similar in a junit test.
Created attachment 13628 [details] The automatic test that fails currently
Created attachment 13629 [details] Thread dump of the starving thread waiting in the openDocumentImpl
Created attachment 13630 [details] The fix I am about to apply
Checking in src/org/openide/text/CloneableEditorSupport.java; /cvs/openide/src/org/openide/text/CloneableEditorSupport.java,v <-- CloneableEditorSupport.java new revision: 1.113; previous revision: 1.112 done Processing log script arguments... More commits to come... RCS file: /cvs/openide/test/unit/src/org/openide/text/Starvation37045Test.java,v done Checking in test/unit/src/org/openide/text/Starvation37045Test.java; /cvs/openide/test/unit/src/org/openide/text/Starvation37045Test.java,v <-- Starvation37045Test.java initial revision: 1.1
Can't agree. Your thread dump is different from the reported one and the difference is significant. I believe that the original starvation was about the state, where documentStatus is DOCUMENT_NO, but prepareTask != NULL. This could happen if one calls prepareDocument and there is an uncaught exception in the load task. Subsequent call to openDocument will deadlock with the same thread dump as the one reported. I've just added such an exception to your test. It deadlocks, but still have different thread dump. To get the same thread dump, the test have to be modified to call prepareDocument() first then wait till the prepareTask sucessfully fails ;-) and then try openDocument.
Nice improvement of the testcase. The main difference seems to be in throwing out an Error and not RuntimeException. If you thrown exception, then the code would work. So I extended the CloneableEditorSupport to also watch for Errors and correctly recover. I am leaving this open and will try to investigate the improvements to the test you mention, but I believe this is no longer high priority issue. Checking in src/org/openide/text/CloneableEditorSupport.java; /cvs/openide/src/org/openide/text/CloneableEditorSupport.java,v <-- CloneableEditorSupport.java new revision: 1.114; previous revision: 1.113 done Processing log script arguments... More commits to come... Checking in test/unit/src/org/openide/text/Starvation37045Test.java; /cvs/openide/test/unit/src/org/openide/text/Starvation37045Test.java,v <-- Starvation37045Test.java new revision: 1.3; previous revision: 1.2
Petr made me to write a test that seems to mimic the original deadlock problem. The fix was very easy. As a result of work on this bug we have discovered three ways how a CloneableEditorSupport can be fooled by unexpected exceptions, we have written tests, so everyone can reliably verify that the wrong behaviour does not repeat and also we have provided fixes, that can be verified by executing the new tests with old code vs. new code. /cvs/openide/src/org/openide/text/CloneableEditorSupport.java,v <-- CloneableEditorSupport.java new revision: 1.115; previous revision: 1.114 done Processing log script arguments... More commits to come... RCS file: /cvs/openide/test/unit/src/org/openide/text/Starvation37045SecondTest.java,v done Checking in test/unit/src/org/openide/text/Starvation37045SecondTest.java; /cvs/openide/test/unit/src/org/openide/text/Starvation37045SecondTest.java,v <-- Starvation37045SecondTest.java initial revision: 1.1
Ok, thanks , I can't reproduce it now - verified