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.
Build: NetBeans IDE 7.3 Beta (Build 201209232010) VM: Java HotSpot(TM) 64-Bit Server VM, 23.3-b01, Java(TM) SE Runtime Environment, 1.7.0_07-b10 OS: Linux User Comments: augcampos: just open the nebeans, with a php project, (open ok in dev build netbeans-dev-201209200001) Stacktrace: java.lang.OutOfMemoryError: Java heap space at java.util.Arrays.copyOf(Arrays.java:2367) at java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:130) at java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:114) at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:415) at java.lang.StringBuffer.append(StringBuffer.java:237) at java.io.StringWriter.write(StringWriter.java:112)
Created attachment 124860 [details] stacktrace
messages.log shows JS parsing.
This seems to be valid. Can you provide your project for testing?
I'm on Fedora 17, 8Gb ram, Netbeans 7.3beta2. This is quite an old bug so I'm not sure if I should try contributing.. I just tried 7.3beta2 for the first time having run 7.2.1 for months with no trouble. Getting OutOfMemory every time, even after closing down most projects. The remaining ones are PHP and Java, but with large javascript libraries (http://dojotoolkit.org) in them. I would suspect the JS, CSS, or some other thing is causing the trouble. It actually brought my system to an absolute halt, I had to hit the Reset button after leaving it trying to scan the project on startup for 20 minutes or so. Xfce completely locked up. I increased -Xmx as much as I could (and still run it without my linux system complaining it couldn't allocate enough contiguous memory) and it still crashed.. ran with HeapDumpOnOutOfMemory and got a 2.5Gb heap dump. Is it worth attaching that, or perhaps reducing my -Xmx so that I get a smaller dump and attach that? I guess gzip or 7zip could reduce it quite a lot. I would think this problem should be easy to reproduce in a project with large JS libraries. Should I try to reproduce it from a clean workspace (not sure how to do that with my 7.2.1 workspace in place)?
It would be great if you can try to reproduce with a recent trunk build from http://bits.netbeans.org/download/trunk/nightly/. Many things have changed since beta2, and there were many fixes in the memory consumption area. Hopefully this will work better for you than the beta2 build. Thanks.
(In reply to comment #5) > Hopefully this will work better for you than the beta2 build. Thanks. Tried today with the latest nightly, 201301260001 .. similar problems although not a complete lock-up, and not an OutOfMemory error as such, though perhaps I didn't leave it long enough. After about 20 minutes it was still scanning (progress bar in status bar stuck on 50%), the GUI was taking several seconds to respond to anything. Just highlighting and indenting rows of code was painful. Memory consumption showed something like 1,800m of 2,200m so it wasn't near 100% memory usage, I don't know if garbage collection was going mad or what else. Perhaps if I had left it longer a complete lock-up would have occurred as before. Output like this is worrying: WARNING [org.netbeans.modules.masterfs.filebasedfs.utils.FileChangedManager]: 2,766 ms in new File("/path/to/project/WebContent/resources/dojo/dojo/tests/_base/loader/i18n-exhaustive/i18n-test/nls").exists() I'm running on an SSD drive, 8Gb dual channel ram, i7 processor, and netbeans 7.2.1 has no such trouble. I could provide a messages.log but would rather not post it publically due to file system contents being logged.
Hello neek, could you please provide the heapdump? Please zip the heapdump.hprof file that should be located in your userdir (default .netbeans/var/log/heapdump.hprof). It would be great if I could have the file. Thanks
(In reply to comment #7) > Hello neek, could you please provide the heapdump? Please zip the Just wanted to report back. I tried a couple of times to leave the RC ide running long enough to generate an OOM condition but always had to interrupt it because of pressing work issues. It's not an easy situation to fit into the day here! On a plus note, I just loaded the recent 7.3 release, and it opened my workspaces fine, ending with 240m in use (when clicking the memory guage to force garbage collection) out of 1128m available, so things seem fine. It would seem that work gone in since this bug was opened have resolved these issues.
Yes, there are a few more fixes that help to improve memory consumption in the final NB 7.3 release. Please reopen if you run in it again. Thanks.