Java Platform, Standard Edition Troubleshooting Guide
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 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.

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.

The next information is the function frame that caused the crash, as shown in Example A-4.

In this example, the "C" frame type indicates a native C frame. Table A-1 shows the possible frame types.

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.

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.


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.

Contents    Previous    Next

Copyright © 1993, 2016, Oracle and/or its affiliates. All rights reserved.