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.
Every time the memory monitor indicate values higher than 300/400MB the error message appear. I got 4Gb RAM, and always more than 2Gb are free.
The important thing is the Xmx setting (as indicated at the website linked from the message), not the overall PC memory size - JVM can only use the memory which is allocated to it. Please attach your messages.log file, so that we can see your Xmx setting from it.
Created attachment 122403 [details] messages.log from nb/var/log/
The messages.log is worthless, because it ends even before system information is displayed - it seems it is from the run which ended too early. Can you please attach another one?
Same error here, I have 16GB ram which means the default Xmx is more than 3GB (I did not change the default). I've changed hardware field to PC/all os because FiruzzZ uses Windows while I use Linux, so I assume it's a cross platform bug. I'm uploading the heap dump, it will take a while.
Created attachment 144096 [details] messages.log
Attached my message log because so the page [1] says, but I'm afraid mine is worthless just like the previous... [1] http://wiki.netbeans.org/InsufficientMemoryToIndexRoot
Please ignore my messages.log, I've just realized it's not even the current one but it's a 3 months old one, I don't even know where NB is writing it these days...
Created attachment 144097 [details] messages.log from my user dir I've finally found the correct message log (in my user dir, not the one in the NB install dir), hope that helps.
Sorry but uploading zipped heap dump of about 200MB is nearly impossible with my internet connection, the upload breaks much earlier (no QoS on my router). I try uploading it to a server I manage (with scp -l), then I send the link here.
Here is the heap dump: http://www.sulweb.org/download/sparsi/heapdump.zip
According to the heap dump org.netbeans.modules.maven.api.NbMavenProject#1 has retained size around 160M. NbMavenProject.files field contains array of 500K instances of java.io.File. It looks like there is a lot of duplicate java.io.File instances. Reassigning to Projects/Maven for further investigation.
Separate issue #240768 was filed for debugger problem.
on each project reload (either explicit by user or implicit after a build) the files list was readded entries for (generated) source roots. all the way up to 150M it appears. The partly obsolete concept/api of NbMavenproject.addWatchedPath is responsible. I've attempted to get rid of it with changeset [1] but didn't manage all the way for time and risk reasons. The *fix* is to stop adding indefinitely but only keep each file only once. That's a bit controversial as it changes behaviour of removeWatchedPath(). Previously the listener was only removed if all occurences were removed from the list, now the first removal removes the listener as well. I've double checked all known codebase and afaik there's little code calling removeWatchedPath() in the first place and if it's there, it's not clashing with other usecases (so the paths should be different) The ideal fix would be getting rid of the watchedPath paradigm altogether and migrate all usages to private listeners via FileUtil.addfileChangeListener(). However with the currently remaining cases, it's risky rewrite. leak fix/workaround: http://hg.netbeans.org/core-main/rev/cfe8456058ff [1] http://hg.netbeans.org/core-main/rev/fcbc8f7ff00f
Integrated into 'main-silver', will be available in build *201401230001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-silver/rev/cfe8456058ff User: Milos Kleint <mkleint@netbeans.org> Log: #216001 memory leak of endlessly accumulating watched paths patched
*** Bug 243167 has been marked as a duplicate of this bug. ***