C.1 Location of Fatal Error Log

The product flag -XX:ErrorFile=file can be used to specify where the file will be created, where file represents the full path for the file location. The substring %% in the file variable is converted to %, and the substring %p is converted to the process ID of the process.

In the following example, the error log file will be written to the directory /var/log/java and will be named java_errorpid.log.

java -XX:ErrorFile=/var/log/java/java_error%p.log

If the -XX:ErrorFile=file flag is not specified, by default the file name is hs_err_pidpid.log, where pid is the process ID of the process.

In addition, if the -XX:ErrorFile=file flag is not specified, the system attempts to create the file in the working directory of the process. In the event that the file cannot be created in the working directory (insufficient space, permission problem, or other issue), the file is created in the temporary directory for the operating system. On Solaris OS and Linux the temporary directory is /tmp. On Windows the temporary directory is specified by the value of the TMP environment variable; if that environment variable is not defined, the value of the TEMP environment variable is used.

C.2 Description of Fatal Error Log

The error log contains information obtained at the time of the fatal error, including the following information, where possible.

The operating exception or signal that provoked the fatal error

Version and configuration information

Details on the thread that provoked the fatal error and thread's stack trace

The list of running threads and their state

Summary information about the heap

The list of native libraries loaded

Command line arguments

Environment variables

Details about the operating system and CPU

Note - In some cases only a subset of this information is output to the error log. This can happen when a fatal error is of such severity that the error handler is unable to recover and report all details.

Note - Note that the format of the fatal error log described here is based on Java SE 6. The format might be different with other releases.

C.3 Header Format

The header section at the beginning of every fatal error log file contains a brief description of the problem. The header is also printed to standard output and may show up in the application's output log.

The header includes a link to the HotSpot Virtual Machine Error Reporting Page, where the user can submit a bug report.

The next information is the function frame that caused the crash, as follows.

# Problematic frame:
# C [libNativeSEGV.so+0x9d7]
| +-- Same as pc, but represented as library name and offset.
| For position-independent libraries (JVM and most shared
| libraries), it is possible to inspect the instructions
| that caused the crash without a debugger or core file
| by using a disassembler to dump instructions near the
| offset.
+----------------- Frame type

In this example, the “C” frame type indicates a native C frame. The following table shows the possible frame types.

Thread Types

Frame Type

Description

C

Native C frame

j

Interpreted Java frame

V

VM frame

v

VM generated stub frame

J

Other frame types, including compiled Java frames

Internal errors will cause the VM error handler to generate a similar error dump. However, the header format is different. Examples of internal errors are guarantee() failure, assertion failure, ShouldNotReachHere(), and so forth. Here is an example of how the header looks for an internal error.

In the above header, there is no signal name or signal number. Instead the second line now contains the text “Internal Error” and a long hexadecimal string. This hexadecimal string encodes the source module and line number where the error was detected. In general this “error string” is useful only to engineers working on the HotSpot Virtual Machine.

The error string encodes a line number and therefore it changes with each code change and release. A crash with a given error string in one release (for example 1.6.0) might not correspond to the same crash in an update release (for example 1.6.0_01), even if the strings match.

Note - Do not assume that a workaround or solution that worked in one situation associated with a given error string will work in another situation associated with that same error string. Note the following facts:

Errors with the same root cause might have different error strings.

Errors with the same error string might have completely different root causes.

Therefore, the error string should not be used as the sole criterion when troubleshooting bugs.

C.4 Thread Section Format

This section contains information about the thread that just crashed. If multiple threads crash at the same time, only one thread is printed.

C.4.1 Thread Information

The first part of the thread section shows the thread that provoked the fatal error, as follows.

The thread pointer is the pointer to the Java VM internal thread structure. It is generally of no interest unless you are debugging a live Java VM or core file.

The following list shows possible thread types.

JavaThread

VMThread

CompilerThread

GCTaskThread

WatcherThread

ConcurrentMarkSweepThread

The following table shows the important thread states.

Thread States

Thread State

Description

_thread_uninitialized

Thread is not created. This occurs only in the case of memory corruption.

_thread_new

Thread has been created but it has not yet started.

_thread_in_native

Thread is running native code. The error is probably a bug in native code.

_thread_in_vm

Thread is running VM code.

_thread_in_Java

Thread is running either interpreted or compiled Java code.

_thread_blocked

Thread is blocked.

..._trans

If any of the above states is followed by the string _trans, that means that the thread is changing to a different state.

The thread ID in the output is the native thread identifier.

If a Java thread is a daemon thread, then the string daemon is printed before the thread state.

C.4.2 Signal Information

The next information in the error log describes the unexpected signal that caused the VM to terminate. On a Windows system the output appears as follows.

siginfo: ExceptionCode=0xc0000005, reading address 0xd8ffecf1

In the above example, the exception code is 0xc0000005 (ACCESS_VIOLATION), and the exception occurred when the thread attempted to read address 0xd8ffecf1.

On Solaris OS and Linux systems the signal number ( si_signo) and signal code ( si_code) are used to identify the exception, as follows.

siginfo:si_signo=11, si_errno=0, si_code=1, si_addr=0x00004321

C.4.3 Register Context

The next information in the error log shows the register context at the time of the fatal error. The exact format of this output is processor-dependent. The following example shows output for the Intel (IA32) processor.

The register values might be useful when combined with instructions, as described below.

C.4.4 Machine Instructions

After the register values, the error log contains the top of stack followed by 32 bytes of instructions (opcodes) near the program counter (PC) when the system crashed. These opcodes can be decoded with a disassembler to produce the instructions around the location of the crash. Note that IA32 and AMD64 instructions are variable in length, and so it is not always possible to reliably decode instructions before the crash PC.

C.4.5 Thread Stack

Where possible, the next output in the error log is the thread stack. This includes the addresses of the base and the top of the stack, the current stack pointer, and the amount of unused stack available to the thread. This is followed, where possible, by the stack frames, and up to 100 frames are printed. For C/C++ frames the library name may also be printed. It is important to note that in some fatal error conditions the stack may be corrupt, and in this case this detail may not be available.

The first thread stack is Native frames, which prints the native thread showing all function calls. However this thread stack does not take into account the Java methods that are inlined by the runtime compiler; if methods are inlined they appear to be part of the parent's stack frame.

The information in the thread stack for native frames provides important information about the cause of the crash. By analyzing the libraries in the list from the top down, you can generally determine which library might have caused the problem and report it to the appropriate organization responsible for that library.

The second thread stack is Java frames, which prints the Java frames including the inlined methods, skipping the native frames. Depending on the crash it might not be possible to print the native thread stack but it might be possible to print the Java frames.

C.4.6 Further Details

If the error occurred in the VM thread or in a compiler thread, then further details may be printed. For example, in the case of the VM thread, the VM operation is printed if the VM thread is executing a VM operation at the time of the fatal error. In the following output example, the compiler thread provoked the fatal error. The task is a compiler task and the HotSpot Client VM is compiling method hs101t004Thread.ackermann.

For the HotSpot Server VM the output for the compiler task is slightly different but will also include the full class name and method.

C.5 Process Section Format

The process section is printed after the thread section. It contains information about the whole process, including thread list and memory usage of the process.

C.5.1 Thread List

The thread list includes the threads that the VM is aware of. This includes all Java threads and some VM internal threads, but does not include any native threads created by the user application that have not attached to the VM. The output format follows.

C.5.2 VM State

The next information is the VM state, which indicates the overall state of the virtual machine. The following table describes the general states.

VM States

General VM State

Description

not at a safepoint

Normal execution.

at safepoint

All threads are blocked in the VM waiting for a special VM operation to complete.

synchronizing

A special VM operation is required and the VM is waiting for all threads in the VM to block.

The VM state output is a single line in the error log, as follows.

VM state:not at safepoint (normal execution)

C.5.3 Mutexes and Monitors

The next information in the error log is a list of mutexes and monitors that are currently owned by a thread. These mutexes are VM internal locks rather than monitors associated with Java objects. Below is an example to show how the output might look when a crash happens when VM locks are held. For each lock the log contains the name of the lock, its owner, and the addresses of a VM internal mutex structure and its OS lock. In general this information is useful only to those who are very familiar with the HotSpot VM. The owner thread can be cross-referenced to the thread list.

C.5.4 Heap Summary

The next information is a summary of the heap. The output depends on the garbage collection (GC) configuration. In this example the serial collector is used, class data sharing is disabled, and the tenured generation is empty. This probably indicates that the fatal error occurred early or during start-up and a GC has not yet promoted any objects into the tenured generation. An example of this output follows.

C.5.5 Memory Map

The next information in the log is a list of virtual memory regions at the time of the crash. This list can be long in the case of large applications. The memory map can be very useful when debugging some crashes, as it can tell you what libraries are actually being used, their location in memory, as well as the location of heap, stack, and guard pages.

The format of the memory map is operating-system-specific. On the Solaris Operating System, the base address and library name are printed. On the Linux system the process memory map ( /proc/pid/maps) is printed. On the Windows system, the base and end addresses of each library are printed. The following example output was generated on Linux/x86. Note that most of the lines have been omitted from the example for the sake of brevity.

In the memory map output, each library has two virtual memory regions: one for code and one for data. The permission for the code segment is marked with r-xp (readable, executable, private), and the permission for the data segment is rw-p (readable, writable, private).

The Java heap is already included in the heap summary earlier in the output, but it can be useful to verify that the actual memory regions reserved for heap match the values in the heap summary and that the attributes are set to rwxp.

Thread stacks usually show up in the memory map as two back-to-back regions, one with permission ---p (guard page) and one with permission rwxp (actual stack space). In addition, it is useful to know the guard page size or stack size. For example, in this memory map, the stack is located from 4127b000 to 412fb000.

On a Windows system, the memory map output is the load and end address of each loaded module, as in the example below.

C.6 System Section Format

The final section in the error log is the system information. The output is operating-system-specific but in general includes the operating system version, CPU information, and summary information about the memory configuration.

On Solaris OS and Linux, the operating system information is contained in the file /etc/*release. This file describes the kind of system the application is running on, and in some cases the information string might include the patch level. Some system upgrades are not reflected in the /etc/*release file. This is especially true on the Linux system, where the user can rebuild any part of the system.

On Solaris OS the uname system call is used to get the name for the kernel. The thread library (T1 or T2) is also printed.

On the Linux system the uname system call is also used to get the kernel name. The libc version and the thread library type are also printed. An example follows.

On Linux there are three possible thread types, namely linuxthreads (fixed stack), linuxthreads (floating stack), and NPTL. They are normally installed in /lib, /lib/i686, and /lib/tls.

It is useful to know the thread type. For example, if the crash appears to be related to pthread, then you might be able to work around an issue by selecting a different pthread library. A different pthread library (and libc) can be selected by setting LD_LIBRARY_PATH or LD_ASSUME_KERNEL.

The glibc version usually does not include the patch level. The command rpm -q glibc might provide more detailed version information.

On Solaris OS and Linux, the next information is the rlimit information. Note that the default stack size of the VM is usually smaller than the system limit. An example follows.

Some systems require swap space to be at lease twice the size of real physical memory, whereas other systems do not have any such requirements. As a general rule, if both physical memory and swap space are almost full, there is good reason to suspect that the crash was due to insufficient memory.

On Linux systems the kernel may convert most of unused physical memory to file cache. When there is a need for more memory, the Linux kernel will give the cache memory back to the application. This is handled transparently by the kernel, but it does mean the amount of unused physical memory reported by fatal error handler could be close to zero when there is still sufficient physical memory available.

The final information in the SYSTEM section of the error log is vm_info, which is a version string embedded in libjvm.so/jvm.dll. Every Java VM has its own unique vm_info string. If you are in doubt about whether the fatal error log was generated by a particular Java VM, check the version string.