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 7.3 Beta 2 (Build 201211062253) Operating System = Linux version 2.6.18-274.17.1.el5 running on amd64 Java; VM; Vendor = 1.7.0_09 Runtime = Java HotSpot(TM) 64-Bit Server VM 23.5-b02 I have a fairly large embedded "existing Makefile" C project. I run a simple edit-compile cycle, but don't debug from within NB. After a day or two with maybe 15 builds per day my heap has grown to around 1.5G and GC pauses become very notable (I run with 2G mem for NB; see excerpt from netbeans.conf below. I tried this increase simply because the slowness was getting unbearable and I thought more memory might do good. But it looks like it simply prolongs the time until I hit the slowness). The thing is, if I build from the command line this doesn't happen. I then tried to see if I could create a simple, reproducible case which would demonstrate my problem, but naively building again and again doesn't seem to trigger it. It looks like I have to do some editing in-between. I have code assistance enabled, and my project has a lot of symbols; maybe that's at play, too. Forcing GC usually frees upwards of a gigabyte of memory, so it doesn't really look like a (major) leak. I don't know how to get closer to the core of the issue; please advise. From netbeans.conf: netbeans_default_options="-J-client -J-Xss2m -J-Xms32m -J-XX:PermSize=32m -J-Xmx2g -J-XX:+UseConcMarkSweepGC -J-XX:+UseParNewGC -J-Dnetbeans.logger.console=true -J-ea -J-Dapple.laf.useScreenMenuBar=true -J-Dapple.awt.graphics.UseQuartz=true -J-Dsun.java2d.noddraw=true -J-Dsun.zip.disableMemoryMapping=true -J-Dsun.awt.disableMixing=true -J-Dnetbeans.extbrowser.manual_chrome_plugin_install=yes"
Created attachment 128846 [details] IDE log
Hi esklid, a hprof memory dump can help to understand the problem.
BTW, while recent refactoring of 'paes' I've seen that there were several leaks that causes objects that hold output to remain in memory even after closing related tabs. (I've almost fixed that - there are still situations when some related holder objects could remain in memory for a while, but not forever - I was planning to re-visit this problem one again later) Not sure if this problem existed before I've started the refactoring, though... (but very likely that it was there)... Also there are some (not essential) leaks in IO libs... But they could not lead to any visible problems I guess... So likely the main leak was fixed recently.. eskild, if you could take the latest build, try it and give a feedback it would be very helpful.
Thanks for input; I'll try the latest build Monday as I'm not at the office today. Re. hprof -- I work with proprietary code, and guess such a dump could potentially spill sensitive data like names, maybe editor buffers too? I'm afraid my employer wouldn't be too impressed by that... Have a nice weekend!
I found one memory leak: - item add itself to data object properties listener in add action in folder - item does not remove itself from data object properties listener in folder So if project has a lot of remove/create build artifacts during build, a lot of old items hung in data object properties listener. The leak was fixed, change set: http://hg.netbeans.org/cnd-main/rev/2706256ab950
fixed another leaked Item http://hg.netbeans.org/cnd-main/rev/e714a9ea9ce4
introduced dedicated factory method for detached view-items http://hg.netbeans.org/cnd-main/rev/7fe9f6a58734 Any more memory leaks?
Integrated into 'main-golden', will be available in build *201212080001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/2706256ab950 User: Alexander Simon <alexvsimon@netbeans.org> Log: fixing Bug #223263 Repeated builds of C project cause slowness
I hope the issue was fixed.
As of today I'm running dev 201212090001; so far memory consumption has peaked at 1.3G and I've had no slowness yet. But this is merely an early observation; it has usually taken a day or two before things become unbearable. Thus, I won't close the bug for another day or two. But looks promising so far.
Been running this for a couple of days now and my max heap has grown less than 100MB during this period. So the fixes have certainly helped -- thanks to all involved! :-) Moving to VERIFIED; should I move CLOSE as well or is that done by some NB member?