JDK-6689685 : Hotspot crash error message should include libraries version
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: hs13
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2008-04-16
  • Updated: 2012-10-13
  • Resolved: 2009-01-30
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6 JDK 7 Other
6u14Fixed 7Fixed hs14Fixed
Description
Hotspot now uses a separate version number from the overall JRE.  It is useful to include both version tags in the crash error message and hs_err log.

The full hs_err log does include the library version in one place, e.g.:
"vm_info: Java HotSpot(TM) Client VM (11.0-b11) for windows-x86 JRE (1.6.0_10-b199)..."
(It's at the bottom of the file.)

However the error message printed to the screen, as well as the header of the hs_err, don't include the libraries version, e.g.:

#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x08abac20, pid=1008, tid=2504
#
# Java VM: Java HotSpot(TM) Client VM (10.0-b19 mixed mode windows-x86)
# Problematic frame:
# v  ~BufferBlob::vtable chunks

We should consider adding the JRE version in at least these 2 places.
Comments
EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/3ad2b8576c4a
09-12-2008
EVALUATION The JDK has a native interface that the VM calls at startup to get the version, that was added in 1.6/6.0. In versions before that once the libraries are initialized, the VM gets the version through checking known classes that exist in the JDK. void *lib_handle = os::native_java_library(); jdk_version_info_fn_t func = CAST_TO_FN_PTR(jdk_version_info_fn_t, os::dll_lookup(lib_handle, "JDK_GetVersionInfo0")); In the case of error handling, this is relatively safe. Using the same mechanism that the launcher use to print out : java -version initializes the class /sun/misc/Version and calls the print function. This seems less safe both to add to startup time (for performance and in the case of an unstable VM) and can't be called at error printing time. The JDK_Version information that we have has less information than the java -version but I think it should be used instead. Eg: ruger% java -version java version "1.6.0_06-p" Java(TM) SE Runtime Environment (build 1.6.0_06-p-b04) Java HotSpot(TM) Server VM (build 13.0-b03, mixed mode) vs. ruger% gamma Queens # To suppress the following error report, specify this argument # after -XX: or in .hotspotrc: SuppressErrorAt=/interpreterRuntime.cpp:79 # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error <made up assertion> # # JRE version: 6.0_06-b04 # Java VM: Java HotSpot(TM) Client VM (14.0-b09-6689685_1208_1554-jvmg mixed mode solaris-x86 ) # An error report file with more information is saved as: # /net/philli/scratch1/coleenp/hg/6689685/make/solaris/solaris_i486_compiler1/jvmg/hs_err_pid8483.log ...
08-12-2008