email article printer friendly more resources

Investigate JVM Crashes
Get to the root cause when no core dump is available
by Rao Akella

February 17, 2005

A JVM is an ordinary process like any other, and it can sometimes terminate unexpectedly. Java has built-in support for handling exceptions, and JVMs can tolerate run-of-the-mill problems better than most. The very exceptional nature of a JVM crash makes it both interesting and important to determine its root cause, since it can be indicative of a serious problem.

A core dump is created usually when a process crashes. A core dump file is a memory map of the running process, and it saves the state of the application at the time of its termination. Therefore, it is important—probably the most important—evidence in determining why the JVM crashed.

Sometimes, however, a core dump is not created, which is like a missing body in a murder mystery, and we are forced to fall back on circumstantial evidence (and sometimes reenact the murder) to determine just what killed the JVM. This scenario is what we'll address here.

Let's look at the symptoms. The application terminates unexpectedly and no core dump can be found related to the crash. This file is usually created in the directory where the JVM was started. On Solaris, it is typically called core, whereas on Linux it is called core.<pid>. BEA's JRockit JVM creates "minidumps" in Windows with the name jrockit.<pid>.mdmp.

In looking at why this problem occurs, it is usually possible to create a core dump when the application handles the exception (which happens when the fatal problem occurs in the JVM's own code). However, if the error occurs in a JNI or JDBC call, or in a third-party library where the exception is unhandled, it's not possible to create a core dump when the operating system terminates the JVM.

A Troubleshooting Checklist
Your checklist for troubleshooting this scenario includes several key items.

Are you sure the JVM crashed? The JVM simply may have exited upon encountering a problem it couldn't handle. However, the JVM will almost always print and/or log a descriptive error message before doing so. For example, when JRockit encounters a fatal JNI error, it prints this message, followed by the error description before it exits:

ERROR: JNI Panic -- Fatal error: ...

Similarly, when JRockit runs out of native (that is, non-heap) memory, it prints this message followed by a description, and then exits:

Fatal error in JRockit ...

JRockit uses native memory for code generation, generated code, optimization, and so on. Being unable to acquire more native memory for internal operations is a serious error that cannot be rolled back or ignored easily. Terminating the JVM may be the best option under exceptional circumstances such as these.

Checking the application log (or the console) for exit-time messages is a quick way to determine if the JVM terminated voluntarily or involuntarily.