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: | [68cat] Editor hangs with 100% CPU | ||
---|---|---|---|
Product: | platform | Reporter: | goeh <goeh> |
Component: | -- Other -- | Assignee: | Antonin Nebuzelsky <anebuzelsky> |
Status: | REOPENED --- | ||
Severity: | blocker | CC: | anebuzelsky, jlahoda, jtulach |
Priority: | P3 | ||
Version: | 6.x | ||
Hardware: | PC | ||
OS: | Windows XP | ||
Issue Type: | DEFECT | Exception Reporter: | |
Attachments: |
Self-sample taken during the printStackTrace() in a loop code sample from the previous comment.
Self-sample taken during the printStackTrace() in a loop code sample when exception dialog is not opened. |
Description
goeh
2009-10-27 15:02:14 UTC
Seems that org.netbeans.core.NbClipboard.eventDispatched is trying to post something into RequestProcessor, which decides to construct stack trace. This blocks, as "Flush UI Logs" thread does something similar. Not related to editor in any way. reassigning to the author of requestprocessor for evalution Who is owner of Platfomr/Other? platform/other has no owner did you evaluate this issue? Seems to me that "AWT-EventQueue-1" blocked in Throwable.getStackTraceElement() and "Parsing & Indexing Loop" blocked in EventQueue.postEventPrivate() are deadlocked. Both are stuck in native code. Tried googling for it, but did not find anything relevant. Not sure why fillInStackTrace is blocking where it is, but note that two other threads are busily doing things with the disk, which is quite likely to make the whole JVM unresponsive. Just a quick note. I waited 10-15 minutes before I created the thread dump. NB was unresponsive all that time. Can you reproduce the problem again and create several thread dumps in a row, e.g. ten thread dumps each after 1 second, and attach this as a textual attachment to this issue? Also, let us know what is the heap utilization and the process memory usage. The java process may either be struggling close to OOME or the process may be heavily swapping memory to disk. INCOMPLETE until additional info is added. Try a loop like this: try { throw new RuntimeException(status); } catch (RuntimeException thrown) { try { while (true) { /* breakpoint here */ Exceptions.printStackTrace(thrown); Thread.sleep(1); } } catch (InterruptedException ex) { Exceptions.printStackTrace(ex); } } When you run until the breakpoint, remove the breakpoint, press continue and place the breakpoint back after 1 second. Your program will break and between 600-1000 exception reports will be printed to NB's output during the next ~2-3 minutes. Now try again and replace the breakpoint after two seconds. Notice your program does not break. During the next 3:10 minutes 1024 error reports will be printed, and only after that, your program will un-freeze and halt at the breakpoint. I found out that the thread printing the exceptions ("Swing-Shell" in the traces above but your own thread in your case) will block at BlockingLinkedList.put() (NB 8.0.2). This will block, not until there is a position in the queue available, but in fact until the queue is empty! I've determined that the queue has a capacity of 1024, and exception 'reports' are processed only a few per second, hence it will unfreeze after some time (as long as the loop generating the exceptions is not running). Created attachment 156358 [details]
Self-sample taken during the printStackTrace() in a loop code sample from the previous comment.
According to the profiler sample, most of the time is spent in AWT-EventQueue-0 during org.netbeans.core.windows.services.NbPresenter.initializeMessage() There is a shuffling with the components even though the Warning (exception) dialog is not showing the details. Since the occupied AWT is a biggest problem for the IDE user, this performance bottleneck should be addressed in NotifyExcPanel. o.n.core/src/org/netbeans/core/NotifyExcPanel.java Created attachment 156472 [details]
Self-sample taken during the printStackTrace() in a loop code sample when exception dialog is not opened.
This profiler snapshot shows threads load during NB run without -ea, therefore exceptions dialog is not opened and all the load is taken by notifications UI.
Again, AWT is the most busy thread, which makes the IDE hard to use.
The problem that was originally reported - AWT-EventQueue-1 blocked at java.lang.Throwable.getStackTraceElement(Native Method) - does not happen in release builds, because SlowItem is not used when assertions are disabled. There is "FileUtil-Refresh-All" running, scanning files, which can slow the system down considerably and "Parsing & Indexing Loop (200910212001)" seems to be reporting exceptions in a loop. This is actually simulated by the code in comment #11. This hang with 100% CPU consumption is a response to an already faulty behavior. We should address the performance bottleneck in AWT event queue at least, to be possible to report the repeated exception. But since this seems to be a rare case and the IDE very likely needs to be restarted anyway to recover, P3 priority is more appropriate IMHO. Scheduling for the next version. |