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.
dev build 200511161900 I'm showing a huge memory leak. After using the IDE for about 2 hours its memory usage went up to 512MB (which is the maximum heap size I configured it to) and the GC was churning away endlessly causing 100% cpu usage for a long while. I had to restart the IDE. The problem is that I don't have any repro steps. I've been seeing some sort of leak for weeks now but it's too random for me to figure out what's actually causing it. I am playing with a standalone Java application (that happens to use Hibernate) so there should be nothing special going on here. I just wanted to give you guys the head's up because beta2 was just released and you wanted to be informed of any major outstanding issues. Well, this is one :) If I find more exact repro steps I'll let you know.
Could you please attach message.log and thread (memory) dump when this happens again? Without it its impossible to track down where memory leaks from :-(
Thanks for head up. Of course more details would be appreciated. OS, JDK version? Can this be related to Hibernate usage (leaking Ant task?)?
Windows XP sp2, JDK 1.5.0_05 and yes I use Hibernate 3.0.5 but I am not sure I am familiar with the Ant task leak you are refering to. I am not using SchemaExport in my ant task (which I remember hearing leaks), just running an application which makes use of Hibernate. Could you please point me to more information on this task leak if it is still relevant?
Is there a way to get thread dumps (which are huge) to go into messages.log? Currently, I run nb.exe and hit ctrl-break to get a thread dump (under WinXP). I really wish I could right click on the memory monitor on the toolbar and "thread/memory dump" into messages.log. It would make it much easier to debug these things.
Another noteworthy item is that I'm using JProfiler (integrated into Netbeans) to memory profile my app. The Netbeans plugin doesn't seem to have an obvious way to shut down a profiler session so I kill the process using the Runtime tab. Maybe this is responsible for the leak I am seeing (just a guess). Do you guys know how to cleanly shut down a JProfiler session from within Netbeans?
> Is there a way to get thread dumps (which are huge) to go into messages.log? I filed an enhancement, issue #69277. > Another noteworthy item is that I'm using JProfiler (integrated into Netbeans) > to memory profile my app. The Netbeans plugin doesn't seem to have an obvious > way to shut down a profiler session so I kill the process using the Runtime tab. I will try to profile that and find out if it causes the leak...
This issue seems to be unrelated to JProfiler. I can reproduce it without ever explicitly launching JProfiler, although you will note the JProfiler plugin still initializes on startup. Another clue.. Around the same time I see high CPU usage and OOME behavior I see "ErrorChecker: null" outputted to the console so whatever operation is outputting that is probably related to the problem. I had an actual thread-dump and stack-trace ready for you from my last OOME but I lost the data :( I will send you that data once I can reproduce the OOME.
thread dumps can be misleading in this context. if there is a memory leak the dumps can show you the activity that ate last free memory and might or might not be related to problem. There are few possibilities: if you could install INSANE module and do a dump at a moment when the memory is almost full the dump file would be very helpful in analyzing the problem. If you are interested I can make it available. Another chance is to migrate to mustang builds and use built-in support for memory dumping described in attached URL. Again this can very likely provide enough data to find what is leaking.
Got it! It's a thread-leak in org.netbeans.modules.tomcat5.util.Utils$Pinger.run(Utils.java:168) I was monitoring Netbeans using JConsole when I started getting 100% cpu usage and I noticed the number of threads keep on increasing linearily and not stopping. I took two thread dumps which prove that over time and more more threads are being spawned from the Pinger class, block on SocketInputStream.read() and then a new Pinger instance is spawned in yet another thread, etc... Please see the attached log file (I copy/pasted the console output).
Created attachment 27263 [details] console output
Oops, I meant to say that *someone* is spawning threads containing the Pinger class (it is not spawning threads itself). PS: Mustang rocks :) These new debugging tools will definately go a long way!
Passing to tomcat module maintainers and raising to P2 - spawning so many threads is a serious defect.
tm->5.0
F. Checking in src/org/netbeans/modules/tomcat5/util/Utils.java; /cvs/tomcatint/tomcat5/src/org/netbeans/modules/tomcat5/util/Utils.java,v <-- Utils.java new revision: 1.5; previous revision: 1.4 done
Verified in 200512061900