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.
Summary: | NB 3.5 RC2 hangs on startup and on project switch | ||
---|---|---|---|
Product: | platform | Reporter: | gthb <gthb> |
Component: | Nodes | Assignee: | Petr Nejedly <pnejedly> |
Status: | VERIFIED WORKSFORME | ||
Severity: | blocker | CC: | mmirilovic |
Priority: | P3 | Keywords: | THREAD |
Version: | 3.x | ||
Hardware: | PC | ||
OS: | Windows ME/2000 | ||
Issue Type: | DEFECT | Exception Reporter: | |
Attachments: |
Thread dump taken from console window (under Win2000)
ide.log for the IDE session that is hanging on startup ide.log from previous IDE session, which terminated normally thread dump on second hang, while changing projects |
Description
gthb
2003-05-22 18:56:30 UTC
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... |