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.
I don't have a test case is for this, but something in the code where it sets the flag designating whether or not to scan the classpath is unsafe. This has just happened to me in RC1 and has happened once before in a daily build. What happens is that I click the run button on the toolbar, the scanning classpath dialog comes up, however it does not scan. It stays up until it is canceled. If i try to execute again and the same things happens. The only way to execute anything again seems to be to restart the IDE. Few things disrupt a good work-flow as much as having to restart the IDE.
Hi, is this issue reproducible in any time or is it random ? some additional information will be welcome as well like, jdk and IDE version, name of operation system you are running on and so on...
I am running RC1 from the main website, not one of the RC1 dailies. I am running this with Java 6 update 1. I am using an older Sony VAIO laptop with a single 2.8Ghz processor and 1.25GB of RAM It has happened to me twice now, once with an RC1 daily and now with the final RC1. It is probably in reaction to doing a build and while it is starting the build process, maybe making an edit. Just things that I have probably done a thousand times before in 5.5.1 and prior. If it is a thread race condition or something, I wasn't sure that trying to create a test case would be a fruitful endeavor; these things can be notoriously hard to reproduce...even if you know what the race condition is. Maybe it is not a race condition at all, but rather something checked and then something else done in a SwingUtilities.invokeLater. Possibly if something happens in the middle in throws invalidates the condition. Possibly the criteria that triggers the classpath scanning to come up is not being checked correctly before the scanning starts. The fact that it doesn't appear to be doing anything (no CPU usage or disk access) leads me to believe that a thread might be waiting for some process to notify() [or signal()] it, and the thing that is supposed to do it never runs. The fact that this condition persists, and the only way to recover is to restart the IDE, seems a good clue for where to look. I wish I would have taken a thread dump when this occurred, as maybe that would also given us another clue. If it happens again, I will certainly do that.
Now there is a brand new final release of NB 6.0. Please try it. I hope that we will be able to close this issue as WORKSFORME.
It has not happened to me yet on the FCS release. If it ever does those, I will definitely report it. If it does happen again, beside trying to remember what I did, what should I include? I can include the thread dump via jconsole... Anything else? It is OK by me if you want to close this issue to tidy things up a bit. I will re-open it if ever happens again.
Ok, closing as WORKSFORME now. Feel free to reopen if you encounter it again. Thread dump could definitely help, maybe even messages.log. If you run NB from console you can capture it pressing CTRL+PAUSE. I believe it is possible to capture it from jconsole as you mentioned but never tried it myself :)