8 About Crash Files

When the JRockit JVM crashes, it creates snapshots of the state of the computer and the JVM process at the time of the crash. These snapshots are in the form of two crash files: a text crash file (.dump); and a binary crash file (.mdmp, a Windows platform minidump or .core, a Linux and Solaris platform core file). The names of the crash files are jrockit.pid.dump and jrockit.pid.mdmp/core, where pid is the process ID (for example, jrockit.72.dump).

You can use information in the crash files to determine the problem that caused the JVM to crash. The information in the crash files is also essential for Oracle Support personnel to help troubleshoot problems with the JVM.

This chapter provides information about the differences between the crash files and how to enable and disable them. It also provides an example of a text crash file and describes how you can use the text crash file for troubleshooting.

This chapter contains the following topics:

8.1 Differences Between Text and Binary Crash Files

Figure 8-1 JRockit JVM Crash Files

Surrounding text describes Figure 8-1 .

You can open the text crash file (.dump) in any text editor. It contains information that can provide hints about the reasons for the crash (see Section 8.6.2, "Example of a Text Dump File."

You can open the binary crash file (.core or .mdmp) in a debugger. The crash file contains information about the entire JRockit JVM process.

8.2 Enabling Crash Files

Creation of crash files is enabled by default.

On Linux and Solaris systems, you must set ulimit -c to a value greater than zero (recommendation: ulimit -c unlimited). This value is measured in blocks, with each block equaling one kilobyte. You can specify the value from either the command line or a shell script.

8.3 Specifying the Location of the Crash Files

The text and binary crash files are saved to the current working directory.

If you want the crash files to be saved in a different directory, specify the directory by using the JROCKIT_DUMP_PATH environment variable.

  • On Linux and Solaris:

    export JROCKIT_DUMP_PATH=path_to_directory

  • On Windows:

    set JROCKIT_DUMP_PATH=path_to_directory

The directory that you specify must exist and must be writable.

8.4 Specifying the Size of the Binary Crash File

The text crash file is a small file, usually under 100KB. The binary crash file, however, is usually very large because, by default, the JRockit JVM logs the entire JVM process in the binary crash file. So you must ensure that there is adequate disk space for the binary crash file to be written to the disk.

You can set the size of the crash file by using the -XXdumpSize command-line option. The default setting is -XXdumpSize:large, which results in a binary crash file that contains information about the entire JVM process, including the Java heap. While small and normal settings are also available, neither of these sizes are adequate for troubleshooting a JVM crash, because, with these settings, the Java heap is excluded from the crash file.

If the disk on which the crash file is written does not have enough space for the binary crash file, the file becomes as large as possible; that is, it fills up the disk.

Figure 8-2 illustrates the differences in information between small, normal, and large binary crash files.

Figure 8-2 Difference in information saturation between small, normal, and large binary crash files

Surrounding text describes Figure 8-2 .

Note:

When you contact Oracle Support, you must provide a large binary crash file.

8.5 Disabling Crash Files

Creation of crash files is enabled by default, so that, if a crash occurs, you can be sure to get as much information as possible about the application and the JRockit JVM process. At times, however, you might want to disable the creation of crash files (for example, when you have limited disk space).

Before disabling the creation of the crash files, note that the text crash file is a small, useful source of information to get an initial understanding of what could be wrong with the JVM. The binary crash file is essential when you contact Oracle Support.

  • You can disable creation of the text crash file by using the -XX:-DumpOnCrash command-line option.

  • You can disable creation of the binary crash file by using the -XX:-CoreOnCrash command-line option.

8.6 Troubleshooting by Using the Text Crash File

A JVM crash indicates that something happened that the JVM could not handle gracefully. The crash could be caused by a programming error in the JVM, a problem in the Java code, a problem in the JVM setup, or third-party libraries loaded in the JVM process.

The text crash file .dump is a good starting point to diagnose the problem.

8.6.1 Symptoms to Look for

A text crash file does not necessarily tell you exactly why the crash occurred, but it describes the environment in which the JRockit JVM was running and the state of the JVM when the crash occurred.

The following are a few easily identifiable symptoms that you can look for in the text crash file:

  • If the StackOverFlow field indicates that stack overflow errors have occurred, the crash is likely to have been caused by a stack overflow.

    Look for reports of Stack Overflow in the Error message field or in the stack trace near the bottom of the crash file. Such occurrences might also indicate a stack overflow.

    For information about troubleshooting a crash caused by a stack overflow, see Section 6.3, "Stack Overflow Crash."

  • If the C Heap field indicates that memory allocations have failed, the process might have run out of virtual memory. For information about troubleshooting crashes caused by virtual memory errors, see Section 6.2, "Out-Of-Virtual-Memory Crash."

If the text crash file shows a symptom different from the symptoms described in this section, try troubleshooting by using the information in Section 6.5, "JVM Crash."

8.6.2 Example of a Text Dump File

This section provides an example of a text crash file (.dump) and describes its parts.

Note that the text crash file does not provide a detailed description of what happened during the crash. The layout of the file that the JVM produces might differ from the layout shown in the example.

Table 8-1 Example of a Text Crash File (.dump)

Section Contents

Beginning of the Text Crash File

 
===== BEGIN DUMP =============================================================
JRockit dump produced after 0 days, 00:00:01 on Mon Dec  7 16:28:40 2009

Additional information is available in:
  /localhome/mycomp/gdbtest/jrockit.17470.dump
  /localhome/mycomp/gdbtest/core or core.17470

Error Message from the Operating System

 
Error Message: Illegal memory access. [54]
Signal info  : si_signo=11, si_code=1 si_addr=0x7

JRockit JVM Version

 
Version      : Oracle JRockit(R) R28.0.0-606-124955-1.6.0_17-20091130-2120-linux-ia32

CPU and Memory Information

 
CPU          : Intel Pentium 4 (HT) SSE SSE2 NetBurst
Number CPUs  : 8
Tot Phys Mem : 8248045568 (7865 MB)

Operating System Version Information

 
OS version   : Red Hat Enterprise Linux AS release 4 (Nahant Update 8)
Linux version 2.6.9-89.0.0.0.1.ELsmp
 (mockbuild@ca-build10.us.oracle.com) (gcc version 3.4.6
 20060404 (Red Hat 3.4.6-11.0.1)) #1 SMP
 Tue May 19 04:23:49 EDT 2009 (i686)

Thread and State Information

 
Thread System: Linux NPTL
LibC release : 2.3.4-stable
Java locking : Lazy unlocking enabled (class banning) (transfer banning)
State        : JVM is running

Command-Line Option Information

 
Command Line : -Djava.library.path=.
 -Dsun.java.launcher=SUN_STANDARD Crash -static write

Environment Information

 
java.home    : /localhome/jrockits/R28.0.0_R28.0.0-606_1.6.0/jre
j.class.path : .
j.lib.path   : .
JAVA_HOME    : /localhome/jrockits/R27.6.3_R27.6.3-40_1.6.0
LD_LIBRARY_PATH: /localhome/jrockits/R28.0.0_R28.0.0-606
  _1.6.0/jre/lib/i386/jrockit:/localhome/jrockits/R28.0.0
  _R28.0.0-606_1.6.0/jre/lib/i386:/localhome/jrockits/R28.0.0
  _R28.0.0-606_1.6.0/jre/../lib/i386

Garbage Collection Information

 
GC Strategy  : Mode: throughput, with strategy: genparpar (basic strategy: genparpar)
GC Status    : OC is not running. Last finished OC was OC#0.
             : YC is not running. Last finished YC was YC#0.
YC History   : Ran 0 YCs since last OC.
Heap         : 0x76eb7000 - 0x7aeb7000  (Size: 64 MB)
Compaction   : (no compaction area)
NurseryList  : 0x76eb7000 - 0x78eb7000
KeepArea     : 0x786b6fe8 - 0x78eb7000
KA Markers   : [ 0x77eb6ff0,  0x786b6fe8 , 0x78eb7000 ]

Registers and Stack Information

 
Registers (from ThreadContext: 0xb7ba4e60:
 eax = 00000007    ecx = b7ba519c   edx = 00000000  ebx = b7ba6f70
 esp = b7ba514c    ebp = b7ba5150   esi = b7ba5178  edi = b7ba70f4
  es = 0000007b     cs = 00000073    ss = 0000007b   ds = 0000007b 
  fs = 00000000     gs = 00000033
 eip = 74405765 eflags = 00000292

Stack:(* marks the word pointed to by the stack pointer)
b7ba514c: 00000007* b7ba5170 7440584c 00000007 b7ba6f70 00000001
b7ba5164: 74bb4405  00000007 00000000 00000001 746a9f80 b7ba70f4
b7ba517c: b7ba519c  00000007 00000000 74bb4400 744842a0 746a9f7b
b7ba5194: b7ba7228  b7ba5178 770643d0 b7ba6f70 00000001 770650d8

Thread Stack Trace Information

 
Thread:
"Main Thread" id=1 idx=0x4 tid=17471 lastJavaFrame=0xb7ba518c
Stack 0: start=0xb71a5000, end=0xb7ba6000, guards=0xb71aa000 (ok), forbidden=0xb71a8000
Thread Stack Trace:
    at write+15()@0x74405765
    at Java_Crash_staticWrite+28()@0x7440584c
    -- Java stack --
    at Crash.staticWrite(J)V(Native Method)[optimized]
    at Crash.run(Crash.java:62)
    at Crash.main(Crash.java:121)
    at jrockit/vm/RNI.c2java(IIIII)V(Native
 Method)[optimized]
    -- end of trace

Memory Usage Information

 
Memory usage report:
Total mapped             1133412KB (reserved=0KB)
-              Java heap 1048576KB (reserved=983040KB)
-              GC tables   35084KB
-          Thread stacks   13332KB (#threads=18)
-          Compiled code     384KB (used=256KB)
-               Internal     520KB
-                     OS    7996KB
-                  Other       0KB
-         JRockit malloc   24448KB (malloced=24397KB #290077)
                                   Does not track allocation sites!

- Native memory tracking    1024KB (malloced=46KB #11)
                                   Does not track allocation sites!

- Java class data           2048KB (malloced=1820KB #2455)
                                   Does not track allocation sites!

Set the env variable TRACE_ALLOC_SITES=1 or use the 
print_memusage switch trace_alloc_sites=1 to enable
 alloc site tracing.

Beginning of the Text Crash File

This part of the .dump file contains information about when the crash occurred and for how long the JVM has been running.

It also provides a link to information to help you troubleshoot the crash.

The file locations refer to the locations of the text and binary crash files.

Error Message from the Operating System

This part of the .dump file contains the error message that the operation threw at the time of the crash. For more information about the error, see the documentation for your operating system.

JRockit JVM Version

This part of the .dump file indicates the release number of the JRockit JVM.

CPU and Memory Information

This part of the .dump file indicates the CPU in the system, the number of CPUs used, and the amount of memory consumed by the Java process, application, or the JRockit JVM.

Operating System Version Information

This part of the .dump file indicates the version of the operating system on which the JRockit JVM is running. Ensure that the JRockit JVM is running on a supported operating system.

For more information, see the see Oracle JRockit JDK Supported Configurations at http://www.oracle.com/technology/software/products/ias/files/fusion_certification.html.

Thread and State Information

This part of the .dump file indicates the thread system that the JRockit JVM used at the time of the crash and the state of the JVM. In this example, the JVM used the Native POSIX Thread Library (NPTL).

Command-Line Option Information

This part of the .dump file shows all the command-line options that were used at JVM startup.

Environment Information

This part of the .dump file provides information about the JVM environment:

  • JAVA_HOME is the path to the Java home catalog; that is, the directory in which the JRockit JVM is installed.

  • _JAVA_OPTIONS shows command-line options that are automatically passed to all newly started JRockit JVMs.

  • LD_LIBRARY_PATH is a Linux- and Solaris-specific environment variable that can make the JRockit JVM find libraries other than the default system libraries. Sometimes, you might have to set this variable for running JNI code.

Garbage Collection Information

This part of the .dump file indicates the garbage collection mode.

Depending on the garbage collection mode used, this part of the .dump file might show other information such as the location of the nursery and keep area in the memory.

Registers and Stack Information

This part of the .dump file provides the following information:

  • The Registers section is useful to Oracle Support personnel for troubleshooting. If the value of the esp register does not match the first number of the stack, the text crash file could be incorrect.

  • If the Stack section shows unreadable, the crash is probably due to a stack overflow. The stack information is usually much longer than that shown in the example.

Thread Stack Trace Information

This part of the .dump file shows what the crashed thread was doing when the JRockit JVM crashed.

Memory Usage Information

This part of the .dump file shows details of memory usage (including native memory).

8.7 Generating Java Heap Dumps in the HPROF Binary Format

HPROF is a heap profiling tool that produces heap dumps in a specific format that heap analysis tools can parse.

You can set up the Oracle JRockit JVM to produce a dump of the Java heap in the HPROF binary format by using the following command-line options:

  • -XX:+HeapDumpOnOutOfMemoryError: Enables generation of Java heap dumps when out-of-memory errors occur.

  • -XX:+HeapDumpOnCtrlBreak: Enables generation of Java heap dumps when you press Ctrl-Break.

For more information about these and other related command-line options, see the Oracle JRockit Command-Line Reference.

You can also generate an HPROF-formatted dump of the Java heap by using the hprof diagnostic command. For more information, see Oracle JRockit JDK Tools.

For information about the HPROF tool, see http://java.sun.com/developer/technicalArticles/Programming/HPROF.html.