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.
After a period of time using the IDE it becomes unresponsive to user input and consumes 50%+ of CPU utilisation. I have note been able to find a reproducible test case, although it seems to happen frequently when I am expanding the methods section of a class in the explorer. Have the IDE configured as SDI, the seperate windows seem to take the focus with the window title color changing as I click around. The content panes of the windows do not update and the only way to recover is to kill the runide process. Have waited several hours to see if the IDE would recover with no success. Does not appear to be related to the GC cycle as the Memory use indicator in the Toolbar has shown various levels of memory use. See attached Thread Dump
Created attachment 21403 [details] Thread Dump
Performance issue. Note it's 3.6.
Can you give us more details? What excatly were you performing (it seems that thread dump was taken when you clicked on an editor gutter to toggle breakpoint). I see VCS, debugger, webapps threads here so it can be hard to judge what is culprit. What is your HW, OS, JDK? Petr: isn't there anything suspicious with the Mutex.enter in AWT thread?
Created attachment 21406 [details] Previous Thread Dump
I have attached a second thread dump taken on an earlier hang. In both cases I had a process that was running in the debugger, but not on a break point, just idle. I have a a Hyperthreading P4 3.0GHz on a Gigabyte 81PE1000P2 MOBO with 1GbDDR RAM running WinXP(SP2) JDK (as per top of thread dump) is Java HotSpot(TM) Client VM (1.4.2_06-b03 mixed mode) I have noticed this occur most frequently when expanding the class tree in the filesystem explorer. I have VSS mounted in the filesystems and do most of my work from there, not the Projects tab. This is happening about once a day, so I will give as much detail as I can when it happens next.
In both thread dumps the finalizer thread is holding the mutex which AWT thread is waiting for. Finalizer is runnable, not waiting on something. So this is not a deadlock! Funny that the IDE did not recover after a few hours. It seems that some other thread must be producing a lot of garbage, perhaps also holding the mutex at that time, and Finalizer has to finalize all that garbage. And the producer thread in the meantime produces more and more garbage, .... and so on. The producer thread might be one of the debugger threads or the search task thread. Could you, please, try doing the same kind of activities in NB 4.0 or the latest NB 4.1? The problem is most probably already fixed after the big rewrites in 4.0... Thanks.
See my last comment above. Closing as fixed in the current release. If you can reproduce in 5.0, please reopen.
closing
c