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.
Mustang b95, 20060808 dev build. Sometimes NB hangs during startup, showing I think "Initializing modules" or similar in the splash screen, and consuming 100% CPU. Has to be killed. When I get thread dumps, it just shows java.lang.IllegalMonitorStateException.<init>(IllegalMonitorStateException.java:31) org.openide.awt.StatusDisplayer.getDefault(StatusDisplayer.java:53) which does not make too much sense to me because this line of SD.java is just returning a field; it is not waiting on anything. VM bug?
Created attachment 33024 [details] Thread dumps
"Done loading modules" is I think the stage it gets to, not that it likely matters.
Ccing experts, I'm just a poor UI guy ;-)
Yes, again I suspect this is a JDK bug but I have no idea how to reproduce it or where to look for more information. I have run into a similar hang a few times in the past. I always run dev builds on Mustang. After killing and restarting NB it starts up fine. Note that the thread dumps span several minutes, during which nothing appears to be happening; everything is inside the one Java line return INSTANCE; which clearly is doing no locking. Presumably the actual bytecode being run is monitorExit. What is also weird: the thread dumps claim that the IllegalMonitorStateException is blocked waiting for a monitor on itself in its own constructor, which does not make a lot of sense.
Note: there's no actual monitorExit bytecode there, sychronized method is just marked as such. The VM would still perform equivalent of monitorExit though. The VM behaviour is really strange as captured in the dumps. You claim 100% cpu usage, which is what would probably happen in case of wrong monitor{enter,exit} pairing, because the code (when using synchonized block) looks like (pseudocode): monitorEnter(); try { body(); } finally { retry: try { monitorExit(); } catch (Throwable) { goto retry(); } } i.e. the monitorExit bytecode is covered with the exception handler as well, so when there is an exception during monitorExit (like the impossible IllegalMSE), it would try to unlock again in a tight loop.
*** Issue 85174 has been marked as a duplicate of this issue. ***
More analysis in issue #85174. VM team hints: ------ There is a very remote chance that this might be being caused by biased locking - though I've only heard reports of IllegalMonitorStateException coming from 5.0 not 6.0 builds. Is this easily reproducible? Things I would try are: 1. Run with -XX:-UseBiasedLocking to disable biased locking 2. Run with a fastdebug build - see if any assertions fail - run with -XX:+TraceExceptions to see where the IMSE originates Can you establish whether the monitor actually appeared to have been locked? ie can you tell if the code in the synchronized method is getting executed.
And possible culprit (analysis pending): http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4414101
pnejedly recommends diagnosis: (gdb) thread apply all backtrace Running with -XX:-UseBiasedLocking is not helpful since bug is not reproducible. Running fastdebug with -XX:+TraceExceptions may be helpful in case the bug ever occurs again.
*** Issue 85554 has been marked as a duplicate of this issue. ***
twolf2919 claims to be able to reproduce this from time to time. Can you please: 1. Generate a native thread dump using gdb: gdb java <pid> (gdb) thread apply all backtrace (make sure you have the tools/process ready in advance. It would be a pity to miss such an opportunity because of missing/nonworking gdb) 2. Once you have the native thread dump, try running with -XX:-UseBiasedLocking for few days. With your claimed probability of hitting the problem, we can be quite sure it is biased-locking related if it doesn't happen to you for a week or so with the flag. Thanks.
Just a clarification note: -XX:-UseBiasedLocking is a JVM flag, so you need to prefix it with -J when passing it to the NetBeans launcher.
Increasing priority to P2 since one of the duplicate was P2 and alaso I think such issues we have to take seriously.
I will definitely do what you suggested as soon as it happens again. But, just so people don't get their hopes up too much: this morning, after reading this thread, I started up netbeans - and it didn't hang! This, after having gotten stuck ever morning last week! On the positive side, now at least I know what to do the next time it happens.
Created attachment 34507 [details] Native thread dump from gdb
I got it to hang again this morning - I attached the native thread dump as per pnejedly's suggestion. It appears the dump gets stuck in Thread 4. Anyway, next few times I will try to remember to run with -XX:-UseBiasedLocking, although I'm not sure what to keep on the lookout for when I do that.
I had to move to JDK b99 and a newer daily of NB6.0 - now I no longer see this startup problem (before I was running b96.) If I come across the problem again, I'll, of course, let everyone know. But, who knows, maybe it was JDK build specific?
*** Issue 85984 has been marked as a duplicate of this issue. ***
JDK problem, apparently fixed in latest JDK6.0 betas.
*** Issue 115632 has been marked as a duplicate of this issue. ***
Created attachment 49925 [details] Wordpad with thread dump & screenshots (.rtf file)
I just uploaded a .rtf file with a thread dump and screen shots. I wound up at this issue via issue number 8554 when researching why my Netbeans was hanging. I was suprised when I started Netbeans using nb.exe instead of the shortcut default netbeans.exe and after copying the thread dump the IDE opened. I got an error message (shown in the attachment) that there was a broken library reference. After fixing all of the broken references by creting new (empty) libraries it started fine. Note: it took me two tries because I only resolved broken references on one project when of course there were two different projects with different missing libraries.
v/c