Contents Previous Next
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.
Example A-1 Sample Header from a Crash
# # An unexpected error has been detected by Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x417789d7, pid=21139, tid=1024 # # Java VM: Java HotSpot(TM) Client VM (1.6.0-rc-b63 mixed mode, sharing) # Problematic frame: # C [libNativeSEGV.so+0x9d7] # # If you would like to submit a bug report, please visit: # http://bugreport.java.com/bugreport/crash.jsp #
Example A-1 shows that the VM crashed on an unexpected signal.
The next line describes the signal type, program counter (pc) that caused the signal, process ID and thread ID, as shown in Example A-2.
Example A-2 Header Format Second Line
# SIGSEGV (0xb) at pc=0x417789d7, pid=21139, tid=1024
| | | | +--- thread id
| | | +------------- process id
| | +--------------------------- program counter
| | (instruction pointer)
| +--------------------------------------- signal number
+---------------------------------------------- signal name
The next line contains the VM version (Client VM or Server VM), an indication whether the application was run in mixed or interpreted mode, and an indication whether class file sharing was enabled as shown in Example A-3.
Example A-3 Header Format Third Line
# Java VM: Java HotSpot(TM) Client VM (1.6.0-rc-b63 mixed mode, sharing)
The next information is the function frame that caused the crash, as shown in Example A-4.
Example A-4 Header Format Fourth Line
# 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. Table A-1 shows the possible frame types.
Table A-1 Frame 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. Example A-5 shows the header format for an internal error.
Example A-5 Header Format for an Internal Error
# # An unexpected error has been detected by HotSpot Virtual Machine: # # Internal Error (4F533F4C494E55583F491418160E43505000F5), pid=10226, tid=16384 # # Java VM: Java HotSpot(TM) Client VM (1.6.0-rc-b63 mixed mode)
In the above header, there is no signal name or signal number. Instead the second line now contains 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:
Therefore, the error string should not be used as the sole criterion when troubleshooting bugs. |