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 just experienced a hang on startup. Not my first startup, IDE was working just fine before. Thread dump indicates that several CVS filesystems are in the middle of updating. One of my mounted CVS filesystems is rooted at a path on my drive that is an ancestor of several other CVS filesystems that I have mounted (code directories within one project directory) -- just mentioning that in case it might be found to be conducive to deadlocks on simultaneous updates. Will attach thread dump, ide.log, and ide.log from the previous IDE session (which did not experience problems)
Created attachment 10384 [details] Thread dump taken from console window (under Win2000)
Created attachment 10385 [details] ide.log for the IDE session that is hanging on startup
Created attachment 10386 [details] ide.log from previous IDE session, which terminated normally
Created attachment 10389 [details] thread dump on second hang, while changing projects
I just submitted a second thread dump, taken when NB 3.5 RC2 is hanging a second time. I don't know whether it is for the same reason, but it seems unlikely that high-resistance mode would be letting deadlocks like this in by the truckloads, so I'm guessing this is related (and thus adding it to the same bug entry). This happened when I was switching between projects, after having worked successfully on one project in the same IDE session for quite a while. As you can see, there is a bunch of RequestProcessor threads sitting around in Object.wait() on some mutex, and one waiting for monitor entry on a mutex. Changing summary accordingly.
Second problem is reported as issue 33398. First hang seems like is releated to CVS and handling with mounted cvs filesystems, so reassigne to vcs for investigation
Passing back to core. This has nothing to do with JavaCVS, there's no deadlock in the thread dump. If there's some problem, it's a disk access (there're 4 threads waiting for disk) or a deadlock in java.awt.KeyboardFocusManager._clearGlobalFocusOwner(Native Method)
Gunnlaugur Thor Briem is it repsoducible in final version 3.5? Thanks in advance
At least I do not remember ever getting this in 3.5 final.
Thanks, I am closing as WORKSFORME.
I see no deadlock either, only a few busy threads. It would be interresting to see the thread dump few seconds later. Anyway, closing as invalid, no deadlock and no apparent problem. If it really hung, it have to be in JVM...