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.
As indicated in nbdev, I've been noticing hangs when I use Alt-G. The hangs don't always occur, but they are frequent enough and long enough to be quite annoying. Some hangs last 5 minutes or so, some much longer. I've only noticed this from NB3.4 beta3 and on. The hangs seem to only happen when I have mounted some filesystems. The stack traces are basically the same. I've seen this with JDK 1.4.1 beta1 on both NT and Linux. Also, I am using the JavaView module ad downloaded from http://contrib.netbeans.org/servlets/ProjectDownloadList?action=download&dlID=191 I'll attach a stack dump from the hang.
Created attachment 6869 [details] stack dump during hang
Peter, can you look at this issue? This seems to be similar to issue #25471 and issue #25185. There is no java parsing thread in the thread dump in all these issues. Thanks.
I've already tried to analyze it on nbdev. Either the parsing task was not posted or the waiter was not notified or the task was posted with loooooong timeout. Or the RequestProcessor is broken.
Whan looking at the ParsingSupport$Processor$T, I'm getting quite nervous as the o.o.u.Task makes sure it will notifyAll() the waiters by a very simple and clear construction, while the code in T and classes around make it harder to proove it will notify(). Anyway, we still don't know what have happened. If it is reproducible enough, we can try to enable logging to see what is going on. Svata/Tomas, can you post how to enable sufficient logging?
I am not sure what type of logging you have in mind, but setting org.netbeans.modules.java.parser.ParsingSupport.DEBUG to true can help.
This is the third report regarding this. (see issue #25471 and issue #25185). And deadlock should have P1.
In fact, this is not a deadlock, it is starvation. I still don't know how can it recover from this state but it may be the key to the real problem. I have two theories: 1. Some asynchronous background thread will ask the java parser for some other info and the parser will finally finish the previous unhandled request by piggybacking it on the new request (is it possible? I saw some piggybacking support in the java module). Note that 25185 have only similar symptomps but is otherwise very different thing. 2. Or the request was posted with very long delay (is it possible? I've not studied the code thoroughly).
John, please try to run NetBeans with -J-Dorg.netbeans.modules.java.parser=-5 and send us ide.log, when you encounter this problem. thanks.
You may also look on issue #24062. At least one of the thread dumps is more than similar to discussed one. The problem in issue #24062 was reliable reproducible just on my machine and on the particular version of IDE (orion). AFAIK, it is not reproducible now.
Well, it may have something to do with the unmount problem mentioned in another issue. I was able to reproduce this reasonably relyably on NT by : mount a filesystem unmount the filesystem use Alt-G to goto a symbol I did have logging on, but I don't have access to the log right now (and it is very large). Is there something I can look for in it?
marking with RELNOTE keyword anything turns up that should be documented in the readme.
I'm attaching another dump I made a couple days ago, this one on NT after unmounting a filesystem.
Created attachment 6893 [details] stack dump while hanging after umounting filesystem
And here is a stack dump I made today, with a bit of logging that occurred after the stack dump. I'm hoping I can get you some more complete logging, but I'll have to reproduce it here (which will happen -- eventually).
Created attachment 6894 [details] stack dump after umounting filesystem, with some logging
John, The last two dumps are quite different beasts. In them, there is actual work being done and the AWT is waiting for this work to finish, while CPU is spinning at full speed. This is probably caused by an interference of the editor, which have the automatic CC database update on filesystem mount (you can try to disable it in Tools->Options->Editing->Editor Settings->Java editor->expert->Update CC->never) and the fact that java module (providing the java parsing services) have only one pipe for parsing requests. In the previous dumps, there was AWT waiting for the parsing results but no parsing was actually performed (CPU was idle). In the previous dumps, there was
Is is also possible that the IDE will get to the state from previous dumps after the actual java parser work finishes without notifiing the last waiter about it, as is hinted by issue 24062 (where the delay that *might* kick down the parsing queue was actualy caused by some blocking dialog) Issue 24062 also hints that the problem is in Java module and not in OpenIDE as the only OpenIDE component that can influence it is the RequestProcessor which was rewritten from scratch for 3.4 yet the problem occured with the old RP in 3.3
This is not P1 issue.
Hi, John, I would like to ask you could you try it with this command line switch?: -J-Dnetbeans.debug.editor.updater=true It should say when the parsing starts&finishes after mounting a filesystem and when (whether) the parsing is killed after unmount. It does not produce much output and could be valuable. Thanks.
John, I am still not able to reproduce it. Can you provide us with more detailed steps how to reproduce it. Thanks.
Well, I downloaded todays stablization build and started from a new userdir and I didn't see the problem all day (on NT). I'll try Linux tonight, but it could be either that this was fixed, or it is related to some state I got the userdir into.
I got another hang on Linux, unfortunately I didn't have the logging on (as I was not trying to reproduce it!). I do have a slightly different stack trace which might be useful.
Created attachment 6906 [details] hang after goto declaration
This bug is reported in version <= 3.4dev and still not fixed. Due to that it forbids the release candidate for 3.4 to be promoted. Are you aware of that and are you intensively working on the fix? If not, you should consider some corrective action.
It looks like we cannot fix it for 3.4. I was told, that solution exists: rewrite all the related code. But this solution is not acceptable in HR mode. I think this issue should be marked with *WAIVER keyword. See http://www.netbeans.org/servlets/ReadMsg? msgId=354390&listName=nbdev Any objections?
Hi, these issues block the 3.4 release. It has been suggested on nbdev that those that are not going to be fixed for 3.4 FCS (waivers) change the target milestone to "future" or "4.0". I'd like to suggest you to do so, if you and your reporter agree on that.
This issue will not be fixed in NB 3.4. I am changing Target milestone to 4.0
Marking with 3.4_WAIVER keyword. See comments above.
Honza, can you summarize when/why this occurs? Are there workarounds or tips to prevent it from happening?
Patrick, we cannot reproduce it here. But we cannot ignore it, because this hang obviously occures. John Richardson reported long hang (~several minutes) when he used Alt-G (Go to Declaration). Although this is a serius bug, it happenes very rarely (as I mentioned before, we cannot reproduce it at all). The only workaround probably is: don't use Go to Declaration.
OK, I'll add a release note that says something like: "The Goto Declaration command (Alt-G)sometimes works very slowly on some systems." If someone can give me suggestions to make this clearer or more precise, please let me know.
To fulfil waiver process cc'ing Honza and Ian.
I agree with the waiver, since the bug seems to be nonreproducible in the QA environment, and seems to be related to specific configuration John uses. The likelihood big number of users will be affected is IMO small.
approved waiver; keep my name in cc for release note purposes
NBDUMP.TXT: The delay is caused by VisualizerNode asking to getChildren(true) [Petr N. had a comment that it improves performance in the source :-)]. Seriously - why is the tree view trying to display and expand the node ? It was not yet expanded in some other view otherwise it would be already parsed - right ? nbhang2.txt is almost unavoidable -- Goto action requested parsing and it is being carried out at Thread.MAX_PRIORITY (which the JVM does not care about :-\) I would suggest to use nonblocking calls to parse a file, then analyse/use its model for Goto decl action implementation. But without a clear "something is being done, please wait" message to the user, this solution could bring even more confusion. At least GUI will not be frozen. hang.txt & hang3.txt both exhibit the same problem as issue #25471: Java Parsing seems to wait with empty request queue, which should not be possible. I will raise the other issue priority and put some diagnostic messages into dev build. Anyone who's able to reproduce that, please watch your console/ide.log.
I had the hang without a parser thread in nb3.4 release. Unfortunately, it seems to occur only when logging is disabled. That is, I ran with logging enabled since my last entry here and had no problems. Since I had no trouble for so long, I took out the logging defines and saw the problem in 8 hours. This was with nb3.4 release and JDK 1.4.1 RC, under RedHat 7.3.
Created attachment 7419 [details] stack dump from hang in nb34 release
*** Issue 25471 has been marked as a duplicate of this issue. ***
Created attachment 7900 [details] dump of problem with New... wizard
In this case it looks like the parser thread died again. Unfortunately, there were no stack traces in the ide.log for this invocation, so I'm not sure why it died.
I was looking in the wrong ide.log! There are plenty of parser errors. lf as the result of getComponent(). This can cause a clash when Component.isValid() is overridden. Please use a separate component class. WARNING - the WizardDescriptor.Panel implementation org.openide.loaders.TemplateWizard2 provides itself as the result of getComponent(). This can cause a clash when Component.isValid() is overridden. Please use a separate component class. *********** Exception occurred ************ at Sat Nov 09 11:32:36 EST 2002 Annotation: Parser error java.lang.StringIndexOutOfBoundsException: String index out of range: 93296 at java.lang.String.<init>(String.java:197) at java.lang.String.copyValueOf(String.java:2233) at org.netbeans.modules.java.gj.V8TreeTranslator.getString(V8TreeTranslator.java:136) at org.netbeans.modules.java.gj.V8TreeTranslator._case(V8TreeTranslator.java:491) at org.netbeans.lib.javac.v8.tree.Tree$VarDef.visit(Tree.java:493) at org.netbeans.modules.java.gj.V8TreeTranslator._case(V8TreeTranslator.java:303) at org.netbeans.lib.javac.v8.tree.Tree$ClassDef.visit(Tree.java:407) at org.netbeans.modules.java.gj.V8TreeTranslator._case(V8TreeTranslator.java:188) at org.netbeans.lib.javac.v8.tree.Tree$TopLevel.visit(Tree.java:344) at org.netbeans.modules.java.gj.V8TreeTranslator.process(V8TreeTranslator.java:94) at org.netbeans.modules.java.gj.ParserEngine.completeRequest(ParserEngine.java:353) at org.netbeans.modules.java.gj.ParserEngine.parseObject(ParserEngine.java:176) at org.netbeans.modules.java.gj.JavaParserEngine.process(JavaParserEngine.java:70) at org.netbeans.modules.java.parser.ParsingSupport$Processor.process(ParsingSupport.java:704) at org.netbeans.modules.java.parser.ParsingSupport$Processor.parseLockModel(ParsingSupport.java:659) [catch] at org.netbeans.modules.java.parser.ParsingSupport$Processor.run(ParsingSupport.java:590) at org.openide.util.Task.run(Task.java:136) at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:599) ==> WARNING - ErrorManager detected cyclic exception nesting: java.lang.StringIndexOutOfBoundsException: String index out of range: 93296 Be sure not to annotate an exception with itself, directly or indirectly. *********** Exception occurred ************ at Sat Nov 09 11:32:37 EST 2002 Annotation: Parser error java.lang.StringIndexOutOfBoundsException: String index out of range: 93202 at java.lang.String.<init>(String.java:197) at java.lang.String.copyValueOf(String.java:2233) at org.netbeans.modules.java.gj.V8TreeTranslator.getString(V8TreeTranslator.java:136) at org.netbeans.modules.java.gj.V8TreeTranslator._case(V8TreeTranslator.java:491) at org.netbeans.lib.javac.v8.tree.Tree$VarDef.visit(Tree.java:493) at org.netbeans.modules.java.gj.V8TreeTranslator._case(V8TreeTranslator.java:303) at org.netbeans.lib.javac.v8.tree.Tree$ClassDef.visit(Tree.java:407) at org.netbeans.modules.java.gj.V8TreeTranslator._case(V8TreeTranslator.java:188) at org.netbeans.lib.javac.v8.tree.Tree$TopLevel.visit(Tree.java:344) at org.netbeans.modules.java.gj.V8TreeTranslator.process(V8TreeTranslator.java:94) at org.netbeans.modules.java.gj.ParserEngine.completeRequest(ParserEngine.java:353) at org.netbeans.modules.java.gj.ParserEngine.parseObject(ParserEngine.java:176) at org.netbeans.modules.java.gj.JavaParserEngine.process(JavaParserEngine.java:70) at org.netbeans.modules.java.parser.ParsingSupport$Processor.process(ParsingSupport.java:704) at org.netbeans.modules.java.parser.ParsingSupport$Processor.parseLockModel(ParsingSupport.java:659) [catch] at org.netbeans.modules.java.parser.ParsingSupport$Processor.run(ParsingSupport.java:590) at org.openide.util.Task.run(Task.java:136) at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:599) ==> WARNING - ErrorManager detected cyclic exception nesting: java.lang.StringIndexOutOfBoundsException: String index out of range: 93202 Be sure not to annotate an exception with itself, directly or indirectly. *********** Exception occurred ************ at Sat Nov 09 11:32:37 EST 2002 Annotation: Parser error java.lang.StringIndexOutOfBoundsException: String index out of range: 92664 at java.lang.String.<init>(String.java:197) at java.lang.String.copyValueOf(String.java:2233) at org.netbeans.modules.java.gj.V8TreeTranslator.getString(V8TreeTranslator.java:136) at org.netbeans.modules.java.gj.V8TreeTranslator._case(V8TreeTranslator.java:491) at org.netbeans.lib.javac.v8.tree.Tree$VarDef.visit(Tree.java:493) at org.netbeans.modules.java.gj.V8TreeTranslator._case(V8TreeTranslator.java:303) at org.netbeans.lib.javac.v8.tree.Tree$ClassDef.visit(Tree.java:407) at org.netbeans.modules.java.gj.V8TreeTranslator._case(V8TreeTranslator.java:188) at org.netbeans.lib.javac.v8.tree.Tree$TopLevel.visit(Tree.java:344) at org.netbeans.modules.java.gj.V8TreeTranslator.process(V8TreeTranslator.java:94) at org.netbeans.modules.java.gj.ParserEngine.completeRequest(ParserEngine.java:353) at org.netbeans.modules.java.gj.ParserEngine.parseObject(ParserEngine.java:176) at org.netbeans.modules.java.gj.JavaParserEngine.process(JavaParserEngine.java:70) at org.netbeans.modules.java.parser.ParsingSupport$Processor.process(ParsingSupport.java:704) at org.netbeans.modules.java.parser.ParsingSupport$Processor.parseLockModel(ParsingSupport.java:659) [catch] at org.netbeans.modules.java.parser.ParsingSupport$Processor.run(ParsingSupport.java:590) at org.openide.util.Task.run(Task.java:136) at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:599) ==> WARNING - ErrorManager detected cyclic exception nesting: java.lang.StringIndexOutOfBoundsException: String index out of range: 92664 Be sure not to annotate an exception with itself, directly or indirectly. *********** Exception occurred ************ at Sat Nov 09 11:32:38 EST 2002 Annotation: Parser error java.lang.StringIndexOutOfBoundsException: String index out of range: 92570 at java.lang.String.<init>(String.java:197) at java.lang.String.copyValueOf(String.java:2233) at org.netbeans.modules.java.gj.V8TreeTranslator.getString(V8TreeTranslator.java:136) at org.netbeans.modules.java.gj.V8TreeTranslator._case(V8TreeTranslator.java:491) at org.netbeans.lib.javac.v8.tree.Tree$VarDef.visit(Tree.java:493) at org.netbeans.modules.java.gj.V8TreeTranslator._case(V8TreeTranslator.java:303) at org.netbeans.lib.javac.v8.tree.Tree$ClassDef.visit(Tree.java:407) at org.netbeans.modules.java.gj.V8TreeTranslator._case(V8TreeTranslator.java:188) at org.netbeans.lib.javac.v8.tree.Tree$TopLevel.visit(Tree.java:344) at org.netbeans.modules.java.gj.V8TreeTranslator.process(V8TreeTranslator.java:94) at org.netbeans.modules.java.gj.ParserEngine.completeRequest(ParserEngine.java:353) at org.netbeans.modules.java.gj.ParserEngine.parseObject(ParserEngine.java:176) at org.netbeans.modules.java.gj.JavaParserEngine.process(JavaParserEngine.java:70) at org.netbeans.modules.java.parser.ParsingSupport$Processor.process(ParsingSupport.java:704) at org.netbeans.modules.java.parser.ParsingSupport$Processor.parseLockModel(ParsingSupport.java:659) [catch] at org.netbeans.modules.java.parser.ParsingSupport$Processor.run(ParsingSupport.java:590) at org.openide.util.Task.run(Task.java:136) at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:599) ==> WARNING - ErrorManager detected cyclic exception nesting: java.lang.StringIndexOutOfBoundsException: String index out of range: 92570 Be sure not to annotate an exception with itself, directly or indirectly. WARNING - ErrorManager detected cyclic exception nesting: java.lang.StringIndexOutOfBoundsException: String index out of range: 93296 Be sure not to annotate an exception with itself, directly or indirectly.
OK, stranger still about 10 minutes after I noticed the problem I got an error manager dialog with the errors from the log in it. After this, the New... wizard worked again. I did a thread dump, and the two blocked threads in nbdump-9-Nov.txt had become unblocked. I'm not sure what is unblocking them. I took a quick look at Task, but didn't see anything obvious (although it might be best not to use synchronized(this)).
*** Issue 29022 has been marked as a duplicate of this issue. ***
As was mentioned before there are really two issues here 1) parser thread dies (or exits without informing waiters) leaving other threads waiting 2) other threads are waiting on parser thread. Nowadays, I almost aways run with Tools->Options->Editing->Editor Settings->Java editor->expert->Update CC->never to minimize #2, but I still see cases where parsing is running (seen in thread dumps) and holds up other operations (like fast open - Alt-Shift-O). Fast open can be held up as long as a minute or two while parsing is run. I'm not sure what is being parsed. I imagine it is the file I have opened in the editor.
We should re-investigate this issue in new projects and java support.
Can not reproduce, decreasing priority to P3. Does anybody knows if the issue still occurs in the NB 3.5 or in the prj40_prototype branch?
Automatic parsing has been reduced, which I think is stopping this problem from showing up more frequently. But, IIRC I have seen this in NB 4.0 dev builds while parsing is occuring. If I see it again I'll attach a stack trace I guess.
Ok, I will try it again :-) Is there any special condition to reproduce it, e.g. Errors in the parsed sources, any exception before it occures?
Tomasi, I'm afraid there is no known special condition. This is the reason why this issue was marked as WAIVER for NB 3.4, NB 3.5 and S1S 5.
If I understand the situation correctly, what's happening is parsing is holding a lock which the AWT thread needs to continue. I've seen this interaction most recently with open class file while parsing. I'd mount a filesystem, start it parsing the java sources, and then Alt-Shift-O. The resulting class file dialog sometimes won't show up for quite a while afterwards. Of course, this was a large filesystem, probably about the size of all the NetBeans sources combined. Whenever I see this, I do a thread dump, and if I see a stack with java.gj in it, I know I can just wait until the parsing is done. (Otherwise I suppose I would have filed a bunch more bugs.)
Removing projects related keywords.
*** Issue 38203 has been marked as a duplicate of this issue. ***
This issue is no more valid. Code relevant to this issue was completely rewritten.
John and anyone who experienced this problem in the past, please play with the trunk builds and verify if it's gone now. Thanks!