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.
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.
I've been working on a Java project for year. My code had been working fine for months. A few days ago I upgraded the Java SDK to the newest version 1.6.0_26 on my Mac (Snow Leopard 10.6.8). After the upgrade, something very weird happens. When I run some of the classes, I get this error:
Invalid memory access of location 0x202 rip=0x202
But, if I run them with -Xint (interpreted) they work, slow but work fine. I get that problem in classes where I use bitwise operators (bitboards for the game Othello). I can't put any code here because I don't get an error, exception or something similar. I just get that annoying message.
Is it normal that the code doesn't run without -Xint but it works with it? What should I do?
Thanks in advance
When a JVM starts crashing like that, it is a sign that something has broken the JVM's execution model.
Does your application include any native code? Does it use any 3rd-party libraries with native code components? If neither is true, then the chances are that this is a bug in the Apple port of the JVM. It could be a JIT compiler bug, or a bug in some JVM native code library.
What can you do about a bug like that?
Not a lot.
Reduce your application by progressively chopping out bits until you have a small testcase that exhibits the problem.
Based on the testcase, see if there's some empirical way to avoid the problem.
Submit a bug report to Apple with the testcase.
I just came across this situation and it turned out to be related to a piece of code that was serializing a JSON object with a cyclic reference to itself. I removed the cycle and the error went away. I suspect this is related to a memory overflow error that is now handled differently by newer JVMs on Mac OSX. In this case, I was running Mac OSX 10.7.
For completeness the errors I was receiving were:
Invalid access of stack red zone 0x10e586d30 rip=0x10daabba6
Bus error: 10
And:
Invalid memory access of location 0x10b655890 rip=0x10a8baba6
Segmentation fault: 11
Also verify that you are building the GUI on the event dispatch thread and never updating a GUI component from any other thread.
Related errors are notoriously hard to reproduce, but the change associated with altered timing is suggestive.
Please check if /etc/hosts is empty and verify that it include these configurations ：
127.0.0.1 localhost
255.255.255.255 broadcasthost
::1 localhost
fe80::1%lo0 localhost
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.
I have java aplication and it started to crash sudently, without no exception. But sometimes JVM creates crash log file, which has name like: "hs_err_pid10930.log". Can anybody read it and tell me what is wrong? I am not able to find out what si wrong. The only reasonable info which I find here is that swap size is 0. I that a problem? How could it occure?
You can find the file here: http://chessfriends-release.s3.amazonaws.com/logs/hs_err_pid10930.log?AWSAccessKeyId=AKIAJP5BYGKOCMCDVZHA&Expires=1305128715&Signature=XEZMuJ0xNSM6YTcdwsI04ahhiYk%3D
Thanks.
Libor
Whenever you get a crash like this it's almost never the Java programmer's fault because the JVM is crashing which it shouldn't. By looking at your log file, it looks like it's crashing somewhere in the OpenJDK's JVM; I don't know what specifically is causing it. I would suggest you try out Oracle's official JDK rather than OpenJDK.
I'm not an expert on reading these sorts of crash dumps, but this is the part I use to identify what is causing the problem:
# Problematic frame:
# V [libjvm.so+0x64d62d]
This is at the top of the dump. It's not always libjvm.so; I've seen some with like libGL.so.
If you would like to file a bug, the dump includes this statement:
# If you would like to submit a bug report, please include
# instructions how to reproduce the bug and visit:
# https://bugs.launchpad.net/ubuntu/+source/openjdk-6/
I don't know what it is you're doing that causes the crash, and maybe there is a workaround. But under no circumstances should the JVM crash, so this is a bug in the JVM you're using.
Edit
The log says you're running Ubuntu 9.10; there have been two Ubuntu releases since then so I doubt filing a bug would do any good unless you test this out on either Ubuntu 10.04 or 10.10. I don't know if you're able to upgrade to a newer version, but your problem may have already been fixed.
I'm trying to get to the bottom of a problem with our Java applet based program. It quite regularly seizes up with an unresponsive GUI (or a white screen). This of course only happens when deployed at a customer site :-(. They are running a version of the Sun JVM in 1.5 series (not sure the exact release).
We have a theory that it's to do with the applet running out of heap space - does that sound plausible? The other thing that I have set up on my machine is disabling direct draw, but that was mainly to avoid weird artefacts on other applications.
They are seeing the problem on Citrix and on regular PCs, but obviously there is a limit to what the users on Citrix can do.
Any suggestions?
Running out of heap space should cause an OutOfMemoryError to be thrown. This case sounds like a typical deadlock. To find where that is you want a stack dump of all the threads. IIRC< you can do it through the console, or from IIRC 1.6 the JDK includes jps and jstack.
First of all ensure the customer uses the latest release of the JVM they are using, and make them enable the Java console inside their browser (this requires some research from you).
Then when it happens again, tell them to look at the console window and cut-paste the contents in a mail to you.
In order to solve the problem, you must first be able to reproduce the problem. You will need an identical system in order to troubleshoot this, making one change at a time while keeping everything else equal to determine the cause(s).
Just to add to this answer (to build the knowledge base as I'm currently looking into this).
There's (at least) 2 distinct white screens related to applets.
Deadlock (as mentioned by Tom) - area will not refresh when you drag a window in front of it, so you get the strange tails left effect.
VM crash - area will become white, Java VM closes (search for hs_err_pid*.log, location dependent on browser)