When I format code in netbeans, I recently started getting an "OutOfMemoryError: Java heap space" error.
I've been using netbeans for well over 2 years and this just started happening on the typical machine I develop on. Currently using version 6.9, on an XP machine, 4Gb memory. I have adjusted -J-Xmx to 1024m and even tried 2048m, and it still get errors.
This is a small php script, less than 100 lines. I have had no problem in the past formatting 10,000+ lines without editing -J-Xmx or anything else. I am not running any code or debugging or unit testing or anything, just the built-in Source -> Format.
I've tried removing code to see if there was a specific section that is causing problems. From what I can gather, if I add a single control structure, no matter what it contains, I get a memory error.
Even:
if($i == 1) {}
causes the memory error. If I check memory usage, Netbeans has no problem using up all of the memory it can. Any help on this would be appreciated.
Here's the stack trace generated when I get the error:
java.lang.OutOfMemoryError: Java heap space
at org.netbeans.modules.php.editor.indent.FormatVisitor.addFormatToken(FormatVisitor.java:1002)
at org.netbeans.modules.php.editor.indent.FormatVisitor.visit(FormatVisitor.java:859)
at org.netbeans.modules.php.editor.parser.astnodes.Program.accept(Program.java:92)
at org.netbeans.modules.php.editor.indent.TokenFormatter$1.run(TokenFormatter.java:354)
at org.netbeans.editor.GuardedDocument.runAtomic(GuardedDocument.java:314)
at org.netbeans.modules.php.editor.indent.TokenFormatter.reformat(TokenFormatter.java:344)
at org.netbeans.modules.php.editor.indent.PHPFormatter.reformat(PHPFormatter.java:129)
at org.netbeans.modules.csl.core.GsfReformatTask$1.run(GsfReformatTask.java:105)
at org.netbeans.modules.parsing.api.ParserManager$UserTaskAction.run(ParserManager.java:154)
at org.netbeans.modules.parsing.api.ParserManager$UserTaskAction.run(ParserManager.java:138)
at org.netbeans.modules.parsing.impl.TaskProcessor$1.call(TaskProcessor.java:200)
at org.netbeans.modules.parsing.impl.TaskProcessor$1.call(TaskProcessor.java:197)
at org.netbeans.modules.masterfs.filebasedfs.utils.FileChangedManager.priorityIO(FileChangedManager.java:160)
at org.netbeans.modules.masterfs.providers.ProvidedExtensions.priorityIO(ProvidedExtensions.java:227)
at org.netbeans.modules.parsing.impl.Utilities.runPriorityIO(Utilities.java:66)
at org.netbeans.modules.parsing.impl.TaskProcessor.runUserTask(TaskProcessor.java:197)
at org.netbeans.modules.parsing.api.ParserManager.parse(ParserManager.java:106)
at org.netbeans.modules.csl.core.GsfReformatTask.reformat(GsfReformatTask.java:95)
at org.netbeans.modules.editor.indent.TaskHandler$MimeItem.runTask(TaskHandler.java:550)
at org.netbeans.modules.editor.indent.TaskHandler.runTasks(TaskHandler.java:317)
at org.netbeans.modules.editor.indent.IndentImpl.reformat(IndentImpl.java:320)
at org.netbeans.modules.editor.indent.FormatterImpl.reformat(FormatterImpl.java:190)
at org.netbeans.editor.ActionFactory$FormatAction$1$1.run(ActionFactory.java:1683)
at org.netbeans.editor.GuardedDocument.runAtomicAsUser(GuardedDocument.java:344)
at org.netbeans.editor.ActionFactory$FormatAction$1.run(ActionFactory.java:1651)
at org.netbeans.modules.progress.ui.RunOffEDTImpl$1.run(RunOffEDTImpl.java:160)
at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1418)
at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:1957)
Looks like there are a ton of similar reports to this issue:
http://statistics.netbeans.org/analytics/exception.do?id=472651
Installed 7.0b and reinstalled JRE 6... which is now working fine. Using 7 as 6.9 is unusable when using code formatting. Would still like to figure out how to fix this issue though.
I found this NetBeans bug which reports a problem which sounds similar to yours. It turned out that the problem was to do with SVN, and was cured by clearing out an SVN cache directory. Read through the bug's "comments" for the details.
Related
When a Java VM crashes with an EXCEPTION_ACCESS_VIOLATION and produces an hs_err_pidXXX.log file, what does that indicate? The error itself is basically a null pointer exception. Is it always caused by a bug in the JVM, or are there other causes like malfunctioning hardware or software conflicts?
Edit: there is a native component, this is an SWT application on win32.
Most of the times this is a bug in the VM.
But it can be caused by any native code (e.g. JNI calls).
The hs_err_pidXXX.log file should contain some information about where the problem happened.
You can also check the "Heap" section inside the file. Many of the VM bugs are caused by the garbage collection (expecially in older VMs). This section should show you if the garbage was running at the time of the crash. Also this section shows, if some sections of the heap are filled (the percentage numbers).
The VM is also much more likely to crash in a low memory situation than otherwise.
Answer found!
I had the same error and noticed that others who provided the contents of the pid log file were running 64 bit Windows. Just like me. At the end log file, it included the PATH statement. There I could see C:\Windows\SysWOW64 was incorrectly listed ahead of: %SystemRoot%\system32. Once I corrected it, the exception disappeared.
First thing you should do is upgrade your JVM to the latest you can.
Can you repeat the issue? Or does it seem to happen randomly? We recently had a problem where our JVM was crashing all over the place, at random times. Turns out it was a hardware problem. We put the drives in a new server and it completely went away.
Bottom line, the JVM should never crash, as the poster above mentioned if your not doing any JNI then my gut is that you have a hardware problem.
The cause of the problem will be documented in the hs_err* file, if you know what to look for. Take a look, and if it still isn't clear, consider posting the first 5 or 10 lines of the stack trace and other pertinent info (don't post the whole thing, there's tons of info in there that won't help - but you have to figure out which 1% is important :-) )
Are you using a Browser widget and executing javascript in the Browser widget? If so, then there are bugs in some versions of SWT that causes the JVM to crash in native code, in various Windows libraries.
Two examples (that I opened) are bug 217306 and bug 127960. These two bug reports are not the only bug reports of the JVM crashing in SWT, however.
If you aren't using the Browser widget then these suggestions won't help you. In that case, you can search for a list of SWT bugs causing a JVM crash. If none of those are your issue, then I highly recommend that you open a bug report with SWT.
I have the same problem with a JNLP application that I have been using for a long time and is pretty reliable. The problem started immediately after I upgraded from Windows 7 to Windows 10. According to my investigation, it is most likely a bug in Win 10.
The following is not a solution, but an ugly workaround. In jre/bin directory, there is javaws.exe. If I right-clicked /Properties/Compatibility and ticked Run this program as an administrator, the JNLP app started to work.
Please, be aware that this approach could cause security issues and use it only if you have no other option and 100% know what you are doing.
When a Java VM crashes with an EXCEPTION_ACCESS_VIOLATION and produces an hs_err_pidXXX.log file, what does that indicate? The error itself is basically a null pointer exception. Is it always caused by a bug in the JVM, or are there other causes like malfunctioning hardware or software conflicts?
Edit: there is a native component, this is an SWT application on win32.
Most of the times this is a bug in the VM.
But it can be caused by any native code (e.g. JNI calls).
The hs_err_pidXXX.log file should contain some information about where the problem happened.
You can also check the "Heap" section inside the file. Many of the VM bugs are caused by the garbage collection (expecially in older VMs). This section should show you if the garbage was running at the time of the crash. Also this section shows, if some sections of the heap are filled (the percentage numbers).
The VM is also much more likely to crash in a low memory situation than otherwise.
Answer found!
I had the same error and noticed that others who provided the contents of the pid log file were running 64 bit Windows. Just like me. At the end log file, it included the PATH statement. There I could see C:\Windows\SysWOW64 was incorrectly listed ahead of: %SystemRoot%\system32. Once I corrected it, the exception disappeared.
First thing you should do is upgrade your JVM to the latest you can.
Can you repeat the issue? Or does it seem to happen randomly? We recently had a problem where our JVM was crashing all over the place, at random times. Turns out it was a hardware problem. We put the drives in a new server and it completely went away.
Bottom line, the JVM should never crash, as the poster above mentioned if your not doing any JNI then my gut is that you have a hardware problem.
The cause of the problem will be documented in the hs_err* file, if you know what to look for. Take a look, and if it still isn't clear, consider posting the first 5 or 10 lines of the stack trace and other pertinent info (don't post the whole thing, there's tons of info in there that won't help - but you have to figure out which 1% is important :-) )
Are you using a Browser widget and executing javascript in the Browser widget? If so, then there are bugs in some versions of SWT that causes the JVM to crash in native code, in various Windows libraries.
Two examples (that I opened) are bug 217306 and bug 127960. These two bug reports are not the only bug reports of the JVM crashing in SWT, however.
If you aren't using the Browser widget then these suggestions won't help you. In that case, you can search for a list of SWT bugs causing a JVM crash. If none of those are your issue, then I highly recommend that you open a bug report with SWT.
I have the same problem with a JNLP application that I have been using for a long time and is pretty reliable. The problem started immediately after I upgraded from Windows 7 to Windows 10. According to my investigation, it is most likely a bug in Win 10.
The following is not a solution, but an ugly workaround. In jre/bin directory, there is javaws.exe. If I right-clicked /Properties/Compatibility and ticked Run this program as an administrator, the JNLP app started to work.
Please, be aware that this approach could cause security issues and use it only if you have no other option and 100% know what you are doing.
So I've been following the tutorial found at http://upandcrawling.wordpress.com/2013/08/16/libgdx-and-google-play-game-service-integration/
And I finally got everything in to my application, but I can't compile it in eclipse. I've looked up ways to change the amount of java space, but none really make sense or apply. This is because with libgdx you can't go into the window and preferences and change settings on a class. The classes used to start libgdx just don't appear
2 major questions:
When I try to compile the application it takes quote a few minutes which it never had done before. Is this Normal or should it still only take approximately a minute.
When I do compile it comes with a dex error, so I know it gets through the basic compiling, but why am I getting a java heap error? after all my app isn't like a 1 GB app, I'd reckon it's only about 10 MB, is there a way to increase data space in eclipse and if so how? (Preferably with screenshots, I'm very visual)
An output of your log files would be helpful in troubleshooting.
This is normal (for me anyway) when I compile it could take several minutes to build everything.
Check out these links:
https://wiki.eclipse.org/FAQ_How_do_I_increase_the_heap_size_available_to_Eclipse%3F
Increasing heap space in Eclipse: (java.lang.OutOfMemoryError)
We have bunch of jar files that are Java applications and run just fine. There are a few however that do nothing although it is expected to run :) with a GUI.
Is this a common issue with jar files that some have difficulties to run?
The OS is Windows 7 and the example not working jar is whitebox a free GIS application, BTW.
We reiterate that we have many jar applications that run like a charm in the above system. This means that it should not be a problem with Java installation (latest update 7u40 exists in the system).
We checked almost all jar failure related topics but no one discussing the issue above which is happening for some applications.
We also mention, we uninstalled and reinstalled java many times but with no success. The application whitebox does nothing. In one try, it did run and when we closed it. And we are since then trying to run it again but nothing is happening! Even nothing appears in the running Processes!
We examined command line and double click. No success. The file type association is correct. Furthermore as we said others are working just fine.
The problem reported was due to inadequate RAM. Whitebox requires 2GB RAM to run smoothly. While this is huge we could run it on an old laptop with only 1GB RAM. The solution was to increase the size of paging file (virtual memory) into the range 1024MB and 2048MB. We also moved its location from C drive into other drives. We the settings mentioned it runs without any problem. We have tried it many times and happy to report for this case the problem is now completely solved.
Conclusion:
For some Java applications if something happend as described in the question it may be due to memory requirement. In this case increasing virtual memory could solve the problem without a need to buy additional RAM.
The auto complete stalls so frequently and for so long, I quit using it altogether.
I've had success with the following using Eclipse (Classic) 3.6.1 on Windows 7 x64.
"A workaround, until the fix is released in 3.6.2 is summarized here: http://groups.google.com/group/android-developers/msg/0f9d2a852e661cba"
(copied for convenience)
"You can replace your /plugins/
org.eclipse.jdt.core_3.6.1.v_A68_R36x.jar plugin with one from
http://www.google.com/url?q=http://adt-addons.googlecode.com/svn/patches/org.eclipse.jdt.core_3.6.1.v_A68_R36x.zip&ei=vg5aTf2RIMrUgAeI-qTvDA&sa=X&oi=unauthorizedredirect&ct=targetlink&ust=1297749446528273&usg=AFQjCNFv7FGlTrnoVhRGE35JPjHxOwI_Bw
and restart Eclipse. Content Assists will be much better. Just try it.
Don't forget backup your original plugins. "
This solved part of my problem.
In preferences, I defaulted all the 'Java->Editor->Content assist' screens and the performance is much improved. Any lag I have now is due to system speed and is negligible. I've gone from minutes to seconds building the suggestion list.
UPDATE: This didn't completely solve my problem, but it got me close. The search continues...
UPDATE: I'm developing in Java for Android using the default packages that are included and any that might have come down during a update(in retrospect, maybe choosing update all in the SDk update might not have been wise). The timing is fairly consistent online and offline. I did a few tests and found the following:
Startup Eclipse and enter a line of code that can use a .toString(). Typing the '.' populates the auto complete within 2-3 seconds. Type a 't' and it takes 70-75 seconds. After that, 10 seconds. Diff objects do the same thing(75 the first time, 10 after that). It's the filtering process that appears to stall. My CPU does not max, Memory is OK, but the program will go not responding till it's done. Any typeahead gets cached and eventually filters the list when Eclipse starts responding.
For me the problem went away when I increased the memory for the vm.
Put this in your eclipse.ini:
-Xms512m
-Xmx1024m
on my 4GB Windows Vista system this would happen A LOT !! (as well as debug issues when looking up variables).
This all went away after I built my new PC with 8GB RAM. I can now run 4 emulators simultaneously and it doesn't have any debug problems any more either. Auto complete with huge lists also works just fine.
it would seem to be just an issue with how much RAM you've got.