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 145807 [details] Thread dump during a slow inspect session Repeatedly using the Source->Inspect functionality on a set of folders, and editing files to resolve the issues, causes the IDE to start to complain about not having enough memory to compile the classes and then to slow down and become unresponsive. During the inspect I selected 'All Anaylers' for the configuration. The attached file is a thread dump during an inspect session where the progress slowed to essentially nothing. I canceled the inspect session and that took a long time to actually cancel. Afterwards I tried to stop the IDE using File->Exit with no response. I grabbed another thread dump and will attach it as well. Eventually the process died via an OutOfMemoryError. When I first encountered the issue I upped the memory to 512MB for subsequent runs but that did not have any effect. If I pick a large enough set of files to inspect it reduces the time until I experience the problem. I just reproduced it by inspecting the entire codebase and then hitting the rerun icon on the inspection output window.
Created attachment 145808 [details] Thread dump while waiting for response to File->Exit
If I run inspect on JEdit 5.1.0 source code, all analyzers, my heap will grow up to almost 2GB and NetBeans will use up to 1.5GB of the heap while scanning. I have my -J-Xmx4096m. Product Version: NetBeans IDE 8.0 (Build 201403052200) Java: 1.7.0_51; Java HotSpot(TM) 64-Bit Server VM 24.51-b03 Runtime: Java(TM) SE Runtime Environment 1.7.0_51-b13 System: Windows 7 version 6.1 running on amd64; Cp1252; en_US (nb)
Reporters: please make a heapdump after analysis finishes and attach to deadlock.netbeans.org - see http://wiki.netbeans.org/FaqMemoryDump for instructions.
Heap dump generated using Apache Commons Collections 4.0 as the project. Uploaded using hudson: http://deadlock.netbeans.org/job/upload/400/
The JavacParsers created by MultiUserAction seems to be stuck in the created sources, so at the time of heapdump collection, there are 74 instances of JavacParser hanging around. Tomasi - is it a leak in Parsing API, or should I call the runUserAction multiple times with less files in batched in a JavaSource object?
Another source which is keeping CompilationInfos is org.netbeans.modules.java.hints.bugs.Unbalanced: seen Map weakrefs the CompilationInfo key, but the value Map refers to Element (ie VarSymbol), which keeps (strong) reference through SharedNameTable to Context (via java.source.TreeLoader) and finally the CompilationInfo and javac parser instance. As a result, the CompilationInfo is never GCed.
When I run Inspect>>Configuration: NetBeans Java Hints on the Apache Common Collection 4.0, I get an exception. See Issue 242757
I now get this exception using the first 11 Inspect & Transform Analyzers on the Apache Commons 4.0 source code. See Issue 245776
This old bug may not be relevant anymore. If you can still reproduce it in 8.2 development builds please reopen this issue. Thanks for your cooperation, NetBeans IDE 8.2 Release Boss