Diagnosing crashes

Many approaches are possible when you are trying to determine the cause of a crash. The process typically involves isolating the problem by checking the system setup and trying various diagnostic options.

Checking the system environment

The system might have been in a state that has caused the JVM to crash. For example, this could be a resource shortage (such as memory or disk) or a stability problem. Check the Javadump file, which contains various system information (as described in Using Javadumps in the J9 VM reference). The Javadump file tells you how to find disk and memory resource information. The system logs can give indications of system problems.

Gathering process information

It is useful to find out what exactly was happening leading up to the crash.

Analyze the core file (as described in Dump viewer in the OpenJ9 user documentation) to produce a stack trace, which will show what was running up to the point of the crash. This could be:
  • JNI native code.
  • JIT or AOT compiled code. If you have a problem with JIT or AOT code, try running without the JIT or AOT code by using the -Xint option.
  • JVM code.
Other tracing methods:
  • ltrace
  • strace

Finding out about the Java environment

Use the Javadump to determine what each thread was doing and which Java™ methods were being executed. Match function addresses against library addresses to determine the source of code executing at various points.

Use the -verbose:gc option to look at the state of the Java heap and determine if:
  • There was a shortage of Java heap space and if this could have caused the crash.
  • The crash occurred during garbage collection, indicating a possible garbage collection fault. See Garbage collector diagnostic data in the J9 VM reference.
  • The crash occurred after garbage collection, indicating a possible memory corruption.

For more information about memory management, see Memory management in the J9 VM reference.