Created attachment 112791 [details]
Thread dump taken while the ide was unresponsive.
Product Version: NetBeans IDE Dev (Build 201111020600)
Java: 1.6.0_26; Java HotSpot(TM) Client VM 20.1-b02
System: Linux version 3.0.0-2-686-pae running on i386; UTF-8; en_US (nb)
User directory: /home/paolo/.netbeans/dev
Cache directory: /run/netbeans
I opened the project panel, opened a directory in the project tree containing about 230 files, mostly images. I selected all the files clicking on the last and while holding the shift key I clicked on the first with the intention of deleting them.
After doing the selection I had no visual feedback of the operation (the selected files didn't change the background color and the processor fan began running faster. After several seconds the files background turned blue and I right clicked on the files to delete them using the context menu but the delete item was disabled.
At this point I noticed a progress bar at the bottom of the window saying "saving snapshot" and NetBeans became progressively unresponsive.
I let NetBeans run for several minutes during which time the CPU was running at 100%, when the progressbar reached 5% a Out of memory error popped up.
The files I was selecting were marked as svn ignore, but I'm not sure it has anything to do with this problem.
Also, I tried to upload the error from netbeans itself using the exception reporter but it ended with another Out of memory.
I attach a thread dump and logs. To take the thread dump I had to use the -F switch after getting the following error from jstack:
941: Unable to open socket file: target process not responding or HotSpot VM not loaded
The -F option can be used when the target process is not responding
Created attachment 112792 [details]
Netbeans messages log
Created attachment 112793 [details]
netbeans metrics file
Created attachment 112794 [details]
netbeans uigestures file
I just noticed that in var/log I have a file called heapdump.hprof.old which is almost 1GB in size:
928270209 Nov 4 01:40 heapdump.hprof.old
If you need it I can try to upload it somewhere.
Please, let me know if I can delete it, thank you.
I can repeat the bug every time I try to select all the files in the same directory. The order in which I select them starting from the first or from the last doesn't change the result. I always get a java.lang.OutOfMemoryError exception.
Maybe because I just started netbeans and the memory used was lower this time the saving snapshot reached 16%. I attach the latest messages.log, since I just started netbeans it should be cleaner.
Created attachment 112811 [details]
messages.log I got after starting netbeans and replicating the issue
Reproducible in a dev build:
for i in 0 1 2 3 4 5 6 7 8 9; do for j in 0 1 2 3 4 5 6 7 8 9; do for k in 0 1 2 3 4 5 6 7 8 9; do touch /tmp/test204645/y$i$j$k.txt; done; done; done
then expand that folder in Favorites and multiselect it.
Seems to be a stack overflow, or at least very deep recursion:
On one attempt to reproduce, I got some stack traces from org.netbeans.modules.project.ui.actions.ActionsUtil.getProjectsFromLookup that I should look up FileObject, not DataObject (bug #199391). This would be fine except this method must be usable for all kinds of selections, and not all of these have been updated to offer FileObject yet (e.g. the form editor). Even when changing that, just selecting the first item and then holding down Shift while extending the selection for a few dozen files results in many stack traces from the explorer which I do not really follow:
java.lang.Exception: Find for /tmp/test204645/x044.gif@5fb73852:e8cc00
and just printing all these is enough to make the IDE slow down to a crawl.
BTW I did not specifically notice OOMEs, just CPU usage. Reporter, if you encounter temporary (recoverable) freezes, the best thing is to reproduce them on a small enough sample that there is a freeze for several seconds but it recovers; then a self-profiler snapshot should automatically get sent to the exception reporter. Or, you can manually Alt-Shift-Y to start and stop the self-sampler, and attach the result to an existing bug report. If you reproduce OOMEs not necessarily connected to freezes, you can use jmap -histo to get a summary of what is wrong.
(In reply to comment #8)
> then a self-profiler snapshot should automatically get sent to the
> exception reporter.
If I do the same operation (select files in the panel) after starting NetBeans I don't get an out of memory error. After selecting the IDE freezes for a few (9-10 seconds) then the "saving snapshot" progress bar appears. The snapshot saving takes a few minutes, I tried to report the "slowness detected" but I can't find the report anywhere on statistics.netbeans.org.
I'm also unable to find the saved snapshot anywhere in the NB home and cache directories, all I can find are the usual log files.
> Or, you can manually Alt-Shift-Y to start and stop the
> self-sampler, and attach the result to an existing bug report.
If I do that it will start saving a snapshot while the slowness detector is already saving one. The saving snapshot stopped at 50% and some partes of the IDE stopped working (i.e. The plugins list in the plugin manager is empty). I didn't get any Out of Memory error, is there any chance the error has been suppressed or the operation halted before the memory limit reached?
I believe the out of memory is due to the IDE using all the memory to save the snapshot rather then the files selection operation.
*** Bug 204476 has been marked as a duplicate of this bug. ***
(In reply to comment #9)
> (In reply to comment #8)
> I tried to report the "slowness detected" but I
> can't find the report anywhere on statistics.netbeans.org.
The server is broken at the moment if I recall correctly - successfully uploading but not showing the result in the IDE.
> I didn't get any Out of Memory error, is there any chance the error has been
Created attachment 113292 [details]
I was able to reproduce the problem by selecting a lot of jpegs in one package (under the source root). The problem is caused by extraordinary deep stack trace in AWT. See attached npss file.
It is hard to debug the problem, so I reported bug 212619 and I am making this one depend on it (in spite the technical solution will not depend on bug 212619).
Created attachment 119559 [details]
An attempt to prevent changes to be fired from ProxyLookup after each beforeLookup
*** Bug 221412 has been marked as a duplicate of this bug. ***
lookup issue, firing too many events. Prob. a dup of #235748