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.
Created attachment 141212 [details] Full thread dump using jstack Suddenly Netbeans enters a bad state with multiple threads spinning indefinitely and the GUI becomes slow. Netbeans process consumes over 300% CPU and it never stops. Restarting IDE looks like only fix, however the problem reappears again after a short while in fresh session, so I suspect I will need to erase the cache folder or something. Edited and saved a web.xml file, and then the problem started. Can't remember seeing this in 7.4-RCs or 7.3.1. Some threads in dump look suspicious: "Refresh-After-WindowActivated" daemon prio=10 tid=0x00007f4a1043c800 nid=0x6381 in Object.wait() [0x00007f49e6180000] "Async FileEvent dispatcher" daemon prio=10 tid=0x00007f4a04287800 nid=0x61fb runnable [0x00007f4a3c823000] A full thread dump is attached from when the problem is occuring. Don't really know which component to file bug against, so I set Ide -> Slowness detector, but the slowness detector actually is NOT triggered in this case.
Looks like Netbeans is indenfinitely stuck with "Checking for external changes" background task.
Wiping cache folder actually didn't help. Problem now re-appeared after a few minutes of heavy indexing (rebuilding caches I guess, Maven repo indexing, etc.). Running Oracle JDK 7u45 x64 btw.
Created attachment 141215 [details] Full thread dump 2 Tried wiping all Netbeans configuration (~/.netbeans/) and cache (~/.cache/netbeans/) and started from scratch. Imported projects and things looked good for while. But suddenly the same problem occured once again. The problem is effectively making Netbeans unusable for me. Attaching new thread dump.
The problem is not directly related to "Checking for external changes", as it also occured with this feature turned off.
(In reply to oyviste from comment #0) > Don't > really know which component to file bug against, so I set Ide -> Slowness > detector, but the slowness detector actually is NOT triggered in this case. Ide/Slowness detector is wrong category. If you don't know the correct component use Ide/Code. To diagnose the problem we need more information. Please attach messages.log and use Profile The IDE! <http://wiki.netbeans.org/FitnessViaPartnership> to attach IDE snapshot to this bug. Thanks.
Created attachment 141265 [details] IDE self sampling npss
Created attachment 141266 [details] Profiler nps
Created attachment 141267 [details] profiler.png
Saved all I could from self profiling. When problem is occuring, Netbeans is extremely slow to respond and sometimes dumps heap, dies or needs kill -9.
Created attachment 141268 [details] messages.log
I reopened the bug now that I've attached more info.
The npss snapshot shows two problems. 1) You are almost running out of memory and a lot of time is spent in GC. 2) There is a huge number of events (file created, file deleted) from filesystem. Do you run some external subversion command on your sources, while netbeans is running? Please try to increase Xmx to 1.5 G and watch for external changes to your source files. Thanks.
Interesting. I'm definitely not doing huge changes to source trees externally when this happens, but I did fire off some Maven builds from within Netbeans. There are two Subversion+Maven projects on the larger side (1500+ java source files and lots of web resources) and one small Git+Maven project. What about the VCS-errors in messages.log ("parent does not exist /tmp/vcs-..", etc.) ? I noticed they were related to some j2ee-module. I uninstalled all J2EE-components (or rather, I re-installed the bare minimum Netbeans j2sdk dist) to see if that would help. I no longer have fancy web.xml editing or server deploy (don't need either), but more importantly I haven't seen the problem yet. Have tried to trigger problem by doing external changes, svn ups, touch all source files in tree, etc. Of course, might just be reduced memory footprint with fewer modules loaded, and that the real fix is to increase heap available to Netbeans. But the projects I'm working on haven't grown significantly lately, and 1G has always been enough before. From what I could observe, the rapdily increasing heap usage starts together with the problem. If that observation is correct, the memory usage is a result of the problem, rather than the cause. (The profiling snapshops are taken after problem started.) I can try reinstalling Netbeans J2EE. Bug has proven to be rather easy to trigger (build+clean, edit a web.xml file and some other files, and suddenly it happens). When reproduced again, I can bump heap to see if it helps.
I am unfortunately unable to reproduce the bug now, after the Netbeans reinstall, even with J2EE modules. So I guess the bug can be closed. Will reopen if I encounter the problem again.