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.
Here is the dump stack: http://openide.netbeans.org/issues/showattachment.cgi?attach_id=2712&file=C:\deadlock.txt Right now I'm not able to reproduce it. The most reproducible case was to restart the IDE with closed editor, then execute ANT compilation of some module (e.g. editor) and then keep double clicking the error line in output window till the editor is opened and line is selected. The dealock is caused by the listener which is attached to document before the document is in state -loaded-. This causes that when the content of document is loaded the event is fired and this result in removal of error annotation. But because this is in "load document" thread, the IDE deadlocks. We discussed this deadlock with Jesse in issue 15933. Please see that issue for more detailed comments.
Cannot remember exact build number, but it was dev build from 2001-09-26 or 2001-09-25
Note that the Ant module is now written differently for other reasons as explained in #15933, so probably the deadlock can no longer be reproduced as mentioned here.
I just reproduced the deadlock. I was running NetBeans in debugging mode with HotSpot turned off. At the moment the deadlock occured, NetBeans was opening file in the editor. The editor window appeared but it stayed empty (filled with gray rectangle). The rest of NetBeans continues to work. I can watch windows and all other windows are repainted when I switch workspaces. I think that this deadlock has nothing to do with the Ant module because I do not use this module (it is disabled). I will attach a full thread dump to this issue.
Created attachment 3004 [details] deadlock - full thread dump
Reassign to new owner of openide/editor
Closing this issues as worksforme. (better would be shouldwork). Reasons: The Marian's thread dump isn't describing deadlock while loading document, I'd say it doesn't describe any deadlock. The issue Marian describes should be caused by differrent kind of problem. So the Jesse's and David's comments should be the correct ones and it should work now.
Deadlock from Marian is not related to this problem. If it appears again I reopen the issue. I still believe that there is -some- problem. If I had more time, I would....
David, please be more specific. If you think there is still a problem with the one described by Jesse and you, let me know about. If you are talking about Marian's problem, it should be filled as separate issue.
Check the dumpstack I attached to this issue. What is there should never happened, but dumpstack proves that it can. I think the problem appeared due to "bad" usage of API. In latest build the code is rewritten so it works fine, but I would try the older build and it should be (hopefully) reproducible.
Reopened, occured again, see the discussion on nbdev Deadlock in 3.3.1 The problem is, there is called getDocument from loading thread. "Loading document org.openide.text.EditorSupport$DelEnv@deb187" daemon prio=2 tid=0x13407830 nid=0xa50 waiting on monitor [196bf000..196bfdb4] at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:426) at org.openide.util.Task.waitFinished(Task.java:86) - locked <05C84AC8> (a org.openide.util.Task) at org.openide.text.CloneableEditorSupport.getDocument(CloneableEditorSupport.java:358) at org.openide.text.DocumentLine.removeAnnotation(DocumentLine.java:305) at org.openide.text.Annotation.detach(Annotation.java:102) at org.netbeans.core.compiler.CompilerDisplayer$AnnotationImpl.detach(CompilerDisplayer.java:485) at org.netbeans.core.compiler.CompilerDisplayer$AnnotationImpl.propertyChange(CompilerDisplayer.java:491) at java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:252) at org.openide.text.Annotatable.firePropertyChange(Annotatable.java:95) at org.openide.text.DocumentLine$Set.fireLineChanged(DocumentLine.java:656) at org.openide.text.LineListener.insertUpdate(LineListener.java:121) at org.openide.util.WeakListener$Document.insertUpdate(WeakListener.java:545) at javax.swing.text.AbstractDocument.fireInsertUpdate(AbstractDocument.java:184) at org.netbeans.editor.BaseDocument.fireInsertUpdate(BaseDocument.java:898) at org.netbeans.editor.BaseDocument.insertString(BaseDocument.java:570) at org.netbeans.editor.Analyzer.read(Analyzer.java:636) at org.netbeans.editor.BaseDocument.read(BaseDocument.java:808) at org.netbeans.editor.BaseKit.read(BaseKit.java:404) at org.netbeans.modules.java.JavaEditor.loadFromStreamToKit(JavaEditor.java:309) at org.openide.text.EditorSupport$Del.loadFromStreamToKit(EditorSupport.java:726) at org.openide.text.CloneableEditorSupport.loadDocument(CloneableEditorSupport.java:1018) at org.openide.text.CloneableEditorSupport.access$1200(CloneableEditorSupport.java:103) at org.openide.text.CloneableEditorSupport$Listener.run(CloneableEditorSupport.java:1432) - locked <05A07670> (a org.openide.windows.CloneableOpenSupport$Listener) at org.openide.util.Task.run(Task.java:152) at org.openide.text.CloneableEditorSupport$1.run(CloneableEditorSupport.java:299) - locked <05A07670> (a org.openide.windows.CloneableOpenSupport$Listener) at org.openide.util.Task.run(Task.java:152) at java.lang.Thread.run(Thread.java:536)
Fixed in [main-trunk]. Fix: openide/../text/CloneableEditorSupport.java [1.55] Note: Its now handled the condition getDocument method is called from loadTask, but better would be to avoid such condition, will create task to try to redesign DocumentLine.
The task is #20951.
Apparantly, this is still an issue in 3.3.1. Attaching new thread dump.
Created attachment 4859 [details] New thread dump.
Sorry, forgot to mention how it happened for me: I compiled a source, which is under VSS control and had errors. Then I got an update to that source from a collegue and copied it over the old source (using Windows Explorer), without checking it out. Since the file was open in the editor, NetBeans tried to refresh it and then deadlocked.
I know it is fixed only in [main-trunk], but should be marked as fixed. I cannot fix it for 3.3.1, it's released already, but can mark it as candidate for 3.3.2, so if it will be made (3.3.2) it will be fixed there. Thanks for it, that's also important.
As I remember this was waiver for 3.3.1 because of too risky fix, so I do not recommend to put this into 3.3.2. It is fixed in 3.4 dev. Peter, please remove the keyword, if you agree, thanks.
*** Issue 21765 has been marked as a duplicate of this issue. ***
Not worth integrating into release33, removed 3.3.2_CANDIDATE keyword.
Risky change. Will not be fixed for FFJ 4.0 (Orion).
Waiver approved.
It seems like it works fine now, verified in [nb_dev] (20021016)
Resolved for 3.4.x or earlier, no new info since then -> closing.