Take the 2-minute tour ×

Guys when the JVM Crashes it writes an Error Log hs_err_pid.log. I want to find out what caused the JVM to crash ? How to understand these Logs, is it documented anywhere on how this Log is arranged. I tried to search on the Net but to no avail :-(

Pointing out to relevant URL's will be appreciated. Thanks.

share|improve this question
add comment

3 Answers

up vote 5 down vote accepted

Unless you are calling native code (JNI), nothing in your code should ever make JVM crash; so the stack trace information in that log file is probably not meant to be very useful to most developers. That's probably why it might not be documented (at least externally). So the best thing is probably to file a bug report as suggested by the error message.

But, if you really do want to understand it, Kohsuke's Blog has the goods. As usual. :)

share|improve this answer
Other evil things can happen that can induce a JVM crash. I've seen it with file system maintenance on the same controller but separate mount points. I've seen it when replacing an existing jar file before stopping the tomcat. (Oops.) I was able to deduce these two causes by the information in the hs_err_pid.log with the folks on the Sun Java forum. –  Stu Thompson May 12 '09 at 7:50
add comment

To start with, look for the topmost line that looks something like "ntdll.dll+0x2000".

If the hotspot is occurring in your native code (i.e. the DLL is one of yours), then find out how to persuade your compiler to produce a list of mappings from DLL offset to line number. Obviously, that may mean you need to re-run with the newly compiled DLL and wait for the problem to occur again.

Otherwise, see if searching for that specific line brings up something in Google, bearing in mind that the same error could mean a whole host of things. And see if the DLL name looks like it's something recognisable, e.g. a printer driver name, graphics driver, or some other component that you can track down to a particular call. Whatever that component is, you may be able to upgrade it to a fixed version, or avoid making the call in question. If you're not sure what the component is, it may just be "the JVM" that you need to upgrade-- upgrading at least to the latest update/minor version nubmer of whatever version you're on is probably a good idea.

In the past I've also seen bugs in the JIT compiler that can be temporarily solved by telling it not to attempt to compile the particular method in question-- as I recall vaguely, in these cases, the hotspot error gives some clue as to which method it was (possibly just the dump of the Java stack), but I don't have an example to hand to recall the details.

share|improve this answer
add comment

this is pretty useful: http://weblogs.java.net/blog/kohsuke/archive/2009/02/crash_course_on.html

ok the first anwser already mentions this url, nevermind

share|improve this answer
add comment

Your Answer


