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.
The thread list includes the threads that the VM is aware of, as shown in Example A-12. 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 a shown in Example A-13.
Example A-13 VM Internal Threads in the Error Log
Java Threads: ( => current thread ) 0x080c8da0 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=21147] 0x080c7988 JavaThread "CompilerThread0" daemon [_thread_blocked, id=21146] 0x080c6a48 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=21145] 0x080bb5f8 JavaThread "Finalizer" daemon [_thread_blocked, id=21144] 0x080ba940 JavaThread "Reference Handler" daemon [_thread_blocked, id=21143] =>0x0805ac88 JavaThread "main" [_thread_in_native, id=21139] Other Threads: 0x080b6070 VMThread [id=21142] 0x080ca088 WatcherThread [id=21148]
The thread type and thread state are described in Thread Section Format.
The next information is the VM state, which indicates the overall state of the virtual machine. Table A-3 describes the general states.
Table A-3 VM States
General VM State | Description |
---|---|
|
Normal execution. |
|
All threads are blocked in the VM waiting for a special VM operation to complete. |
|
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)
The next information in the error log is a list of mutexes and monitors that are currently owned by a thread, as shown in Example A-14. 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.
The next information is a summary of the heap, as shown in Example A-15. 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.
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 Oracle 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. Example A-16 shows the output generated on Linux/x86. Note: Most of the lines have been omitted from the example for the sake of brevity.
Example A-17 Format of Memory Map in the Error Log
40049000-4035c000 r-xp 00000000 03:05 824473 /jdk1.5/jre/lib/i386/client/libjvm.so |<------------->| ^ ^ ^ ^ |<--------------------------------->| Memory region | | | | | | | | | | Permission --- + | | | | r: read | | | | w: write | | | | x: execute | | | | p: private | | | | s: share | | | | | | | | File offset ----------+ | | | | | | Major ID and minor ID of -------+ | | the device where the file | | is located (i.e. /dev/hda5) | | | | inode number ------------------------+ | | File name --------------------------------------------------+
Example A-17 shows 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 shown in Example A-18.
The next information in the error log is a list of VM arguments, followed by a list of environment variables, as shown in Example A-19.
Note: The list of environment variables is not the full list but rather a subset of the environment variables that are applicable to the Java VM. |
On Oracle Solaris and Linux operating systems, the next information in the error log is the list of signal handlers, as shown in Example A-20.