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.
Product Version = NetBeans IDE 8.1 (Build 201510222201) Operating System = Linux version 3.13.0-87-generic running on amd64 Java; VM; Vendor = 1.8.0_51 Runtime = Java HotSpot(TM) 64-Bit Server VM 25.51-b03 Reproducibility: Tried, but couldn't reproduce it This feels a lot like https://netbeans.org/bugzilla/show_bug.cgi?id=254845 and may be the same issue. At apparently random times, NetBeans becomes very, very sluggish. When in this state, it consumes 100% of every CPU core on my system. The NB UI is so unresponsive that I cannot start a self profiling session. It consumes so much CPU that I can't even get Visual VM to get a list of running java applications on the system. I was able to get some stack traces using jstack. stack.txt and stack2.txt are stack traces taken while the problem is occuring. stack_normal.txt is a stack trace taken after killing and restarting NB. My guess is that thread "Data System Nodes for /usr/lib/jvm/java-1.7.0-openjdk-amd64/jre/lib/rt.jar" is the culprit, as I don't see it in the normal stack trace. This has been happening several times a day.
Created attachment 159983 [details] Stack trace during problem
Created attachment 159984 [details] Another stack trace during problem
Created attachment 159985 [details] Noraml, non-problem stack trace
Created attachment 159986 [details] Log file for the problem occurence that matches the stack traces
I've noticed that this seems to happen frequently when I'm editing a file name fullbuild.xml in one of my web projects. fullbuild.xml is an ant build file that I use when building the application for production deployment. Please let me know if the contents of that file would be helpful.
I am 96.513% certain that this is triggered when I open my fullbuild.xml file in NetBeans. (I use this filename in several of my projects.) I'm trying to train myself to open it in an external editor to make changes, but old habits die hard. :)
This is still a problem in netbeans-dev-201607210002
Has happened twice today in netbeans-dev-201607210002. If anyone is working on / looking at this... How can I get the diagnostics you need? The NB self-profile button isn't an option - when this happens the UI is either completely non-responsive or so slow that it is unusable.
Then please use VisualVM [1] tool to generate a profiling snapshot for us. Thanks. [1] https://visualvm.java.net/
Attached is a VisualVM snapshot taken during an instance of this problem today, and a screen shot of that while it was collecting.
Created attachment 161387 [details] VisualVM snapshot
Created attachment 161388 [details] VisualVM screen shot while running
Thanks for the nps file from VisualVM. However it is not clear what is going - it looks like the whole system is slow. I would like to get VisualVM application snapshot - this will also persist graphs from 'Monitor' tab. So next time please create snapshot from sampling (nps) and than create VisualVM's application snapshot for NetBeans process. More info about application snapshot is here: https://visualvm.java.net/snapshots.html
Created attachment 161680 [details] Visual VM Application snapshot Here is the application snapshot as requested.
Created attachment 161682 [details] better Visual VM snapshot Use the nb2....apps snapshot instead. The first one did not have the sampling in it.
Created attachment 161703 [details] Another VisualVM Snapshot Here is another snap shot from Visual VM. I did the CPU sampling before taking the snapshot, but it doesn't appear to be in the file. Weird. I've noticed the last couple of times this has happened, it seems to be triggered about the time I do a git "add" on a new project.
(In reply to mclaborn from comment #16) > Created attachment 161703 [details] > Another VisualVM Snapshot > > Here is another snap shot from Visual VM. I did the CPU sampling before > taking the snapshot, but it doesn't appear to be in the file. Weird. You need to take snapshot of CPU sampling data first and than do the application snapshot.
Duh. Feeling sheepish.
(In reply to mclaborn from comment #16) > Created attachment 161703 [details] > Another VisualVM Snapshot > > Here is another snap shot from Visual VM. I did the CPU sampling before > taking the snapshot, but it doesn't appear to be in the file. Weird. You need to take snapshot of CPU sampling data first and than do the application snapshot. (In reply to mclaborn from comment #15) > Created attachment 161682 [details] > better Visual VM snapshot > > Use the nb2....apps snapshot instead. The first one did not have the > sampling in it. The application snapshot shows that this is a memory problem. Monitor graphs show that GC is running constantly and is not able to free any memory. Try to run NetBenas with Xmx3G - let us see if it helps.
It was already Xmx2500m. I changed to 3G. Watching...
(In reply to mclaborn from comment #20) > It was already Xmx2500m. Yes, I know. >I changed to 3G. Watching... OK.
Created attachment 161722 [details] Another snapshot wit MX=3G Running with 3G is better - when this happens the NB UI still gets VERY slow, but it does respond to inputs every once in a while (maybe 30 seconds or so), whereas before it was much slower to respond, if ever. Attached is another snapshot.
(In reply to mclaborn from comment #22) > Created attachment 161722 [details] > Another snapshot wit MX=3G > > Running with 3G is better - when this happens the NB UI still gets VERY > slow, but it does respond to inputs every once in a while (maybe 30 seconds > or so), whereas before it was much slower to respond, if ever. > > Attached is another snapshot. The snapshot shows the same picture. This is still memory problem and 3G is still not enough. Please use Xmx3600M and re-run NetBeans. In addition please also take snapshot from Memory sampling. This can roughly show us what is taking memory. It would be great to have steps how to reproduce it.
Created attachment 161727 [details] memory and CPU sampling snapshot Here is another snapshot with memory and CPU sampling. I can't reproduce this at will, but my fullbuild.xml file (see above) is almost always open. This time it seemed to start immediately when I opened that file.
(In reply to mclaborn from comment #24) > Created attachment 161727 [details] > memory and CPU sampling snapshot > > Here is another snapshot with memory and CPU sampling. > > I can't reproduce this at will, but my fullbuild.xml file (see above) is > almost always open. This time it seemed to start immediately when I opened > that file. Hmm, this is hard to tell. Anyway the snapshot shows that the situation is better. I can even see that GC was able to reclaim some memory. The memory snapshot shows a large number StackTraceElement object. Can you please try to run NetBebeans with disabled assertions - dev. build you are using have them enabled by default. To disable assertions please edit netbeans.conf file a change -J-ea to -J-da Run NetBeans with the same Xmx. IF you did it correctly the memory sampler should not show StackTraceElement instances at the top of histogram.
Created attachment 161746 [details] snapshot with assertions disabled Here is another snapshot with assertions disabled. I THINK that the same background operation was going on, but can't be sure. The UI was sluggish occasionally, but then it would be normal for a good while. I was editing in my fullbuild.xml file which usually triggers this and I saw a period of high CPU usage. I did not have to kill or close NetBeans this time (yeah)! The stack traces don't show up at the top the memory snap shot any more. It is at least possible that the background task was finished before I took the snapshot.
(In reply to mclaborn from comment #26) > Created attachment 161746 [details] > snapshot with assertions disabled > > Here is another snapshot with assertions disabled. > I THINK that the same background operation was going on, but can't be sure. > The UI was sluggish occasionally, but then it would be normal for a good > while. I was editing in my fullbuild.xml file which usually triggers this > and I saw a period of high CPU usage. I did not have to kill or close > NetBeans this time (yeah)! Yes, the graphs looks more or less OK. > The stack traces don't show up at the top the memory snap shot any more. Memory snapshot looks similar to issue #262456. > It is at least possible that the background task was finished before I took > the snapshot. Yes, previous snapshots show heavy computation of Data System Nodes for various libraries from your project.
Where do we go from here on this issue? Do you still want me to get snapshots? I noticed today that this happened when I did a Ctrl + Click to navigate to the source of a method that is in a class library attached to my project. This particular library does not have source, only the compiled jar file. When it does happen, the NB GUI gets slow for a while and then recovers.
(In reply to mclaborn from comment #28) > Where do we go from here on this issue? > Do you still want me to get snapshots? > > I noticed today that this happened when I did a Ctrl + Click to navigate to > the source of a method that is in a class library attached to my project. > This particular library does not have source, only the compiled jar file. > > When it does happen, the NB GUI gets slow for a while and then recovers. I think this can be closed as duplicate of issue #262456. It would be great if you can put together steps how to reproduce it.
*** This bug has been marked as a duplicate of bug 262456 ***