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 Dev (Build 201112130600) Java: 1.7.0_01; Java HotSpot(TM) Client VM 21.1-b02 System: Windows 7 version 6.1 running on x86; Cp1252; en_US (nb) User directory: C:\Users\g.tzabari\.netbeans\dev Cache directory: C:\Users\g.tzabari\.netbeans\dev\var\cache I've noticed that dev builds over the past couple of weeks seem to leak memory fairly fast. After 2 hours of usage my IDE went from 200MB heap to 600MB. I don't have repro steps but I keep on running across bug 206185 so it might be related (maybe it leaks memory every time an exception is thrown... just a guess). In any case, how do we investigate this further?
reassign to performance team for further investigation
(In reply to comment #0) > > In any case, how do we investigate this further? You should use the IDE till OutOfMemoryError happens. Once it happens, IDE should automatically report this OOME via exception reporter and it also attaches compressed heap dump. This should be enough for us to start investigating the issue.
This doesn't work. When the OOME occurs, the IDE is so unresponsive it never finishes sending the heap dump. Either that, or the dump is too big. I took a look and the generate dump is 1.3GB. Even if I force the IDE to use a smaller max memory I expect the heap dump to be 100s of MBs. What should I do?
Please share(for example via megashare or some similar service) with us the Zipped! heap dump - you can find it in YourNetbeansUserDir/var/log/
I took a quick look at the heap dump and I see 3 major offenders: JavadocEnv$JavadocField (428MB, 35%) Symbol$VarSymbol (396MB, 33%) HeapMap$Entry (181MB, 15%) I've also managed to compress the heap dump to 111MB. I'm going to try reproducing the OOME with a smaller heap (250MB). Hopefully I'll end up with a compressed heap dump of 10MB...
Sorry, I'll keep the issue closed until I've attached the dump.
(In reply to comment #5) > I took a quick look at the heap dump and I see 3 major offenders: > > JavadocEnv$JavadocField (428MB, 35%) > Symbol$VarSymbol (396MB, 33%) > HeapMap$Entry (181MB, 15%) > > I've also managed to compress the heap dump to 111MB. I'm going to try > reproducing the OOME with a smaller heap (250MB). Hopefully I'll end up with a > compressed heap dump of 10MB... Ok, thanks. We are looking for the heap dump...
Here is a heap dump I generated for -Xmx250m: http://www.megaupload.com/?d=1S48022C Let me know if it's enough. Otherwise I will attached the larger heap dump which is 111MB.
(In reply to comment #8) > Here is a heap dump I generated for -Xmx250m: > http://www.megaupload.com/?d=1S48022C Why this is rar archive? Can't you use zip?
There is a significant size difference (40MB to 57MB). Even more so for the large heap dump. I can re-upload the dump in the form of a zip if I must but I'd rather avoid it. Let me know.
(In reply to comment #10) > There is a significant size difference (40MB to 57MB). Even more so for the > large heap dump. I can re-upload the dump in the form of a zip if I must but > I'd rather avoid it. Let me know. You can leave it as it is, but please don't use rar in the future.
Zipped heap dump is here: http://netbeans.org/projects/profiler/downloads/download/Heapdumps/heapdump-206586.zip
Fixed in jet-main. http://hg.netbeans.org/jet-main/rev/aeae74c6a3a7 details: http://hg.netbeans.org/main/nb-javac/rev/7a90b1a33410
Integrated into 'main-golden', will be available in build *201201250600* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/aeae74c6a3a7 User: Dusan Balek <dbalek@netbeans.org> Log: Issue #206586: Memory leak - fixed. Do not create JavaDocs for local variables.