Bug 25934

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!