tags:

views:

169

answers:

3

I am trying to analyze a JVM crash that is occuring inconsistently. I get a hs_err_pid312.log file when it happens.

i've added Thread.setDefaultUncaughtExceptionHandler(new Thread.UncaughtExceptionHandler(), but i'm not sure that will catch the error.

What other things can i do so the next time this occurs, i can get as much information as possible?

thanks

A: 

JVM crashes are generally caused by segmentation violations or other low-level operations, and won't be handled as exceptions.

The logfile should provide you all the information you need: it will show the machine stack trace at the time of the crash, the current PC value, and the memory map. If you refer to the memory map, you'll see what library was being used at the time of the crash (although that's not always valid, particularly if something else munged the stack so you returned to the wrong location).

Generally, these problems occur with JNI code that's not well-behaved. so I'd recommend starting there.

kdgregory
A: 

Okay, you need to look at the CONTENTS of that log file, but in general (after a little googling) I see it's the result of the hotspot version of the JVM hitting an unrecoverable error on a Windows machine. Most of the examples seem to be something like an unresolveable symbol in a DLL.

Charlie Martin
+1  A: 

The hs_err file looks pretty daunting but can be helpful if you know what to look for. You might want to check out Java Troubleshooting and Diagnostics Guide; section 2.2 in particular. That section describes how to make sense of what HotSpot is trying to tell you. Section 2.2.2 details several sample crashes and hints at what might be behind it.

If you see something about "grow array" in the hs_err file header then your problem is likely an OutOfMemoryError. Normally the JVM should exit gracefully under such conditions, but non-daemon threads in your application can prevent this.

JLR