JDK-8046266 : [TEST_BUG] sun/misc/Version/Version.java doesn't match JVM version after 8030011
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 9
  • Priority: P4
  • Status: Resolved
  • Resolution: Cannot Reproduce
  • OS: generic
  • CPU: generic
  • Submitted: 2014-06-06
  • Updated: 2014-10-06
  • Resolved: 2014-10-06
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 9
9Resolved
Related Reports
Relates :  
JDK-8032678 - [TEST_BUG] sun/misc/Version/Version.java doesn't understand two-digit HotSpot minor version numbers
Description
sun/misc/Version/Version.java

After 8030011 changes JVM version string changed to match JDK version:
java version "1.9.0-ea"
Java(TM) SE Runtime Environment (build 1.9.0-ea-b07)
Java HotSpot(TM) Server VM (build 1.9.0-ea-b07, mixed mode)

Looks like Version.java test was not fixed to accept new version string:

----------System.out:(4/223)----------
newVersionInfo: input=1.9.0-ea-fastdebug-b15 output=1.9.0-b15
JDK version = 1.9.0-b15  1.9.0-b15
newVersionInfo: input=1.9.0-internal-201406050912.anoll.JDK-8031389-fastdebug output=1.9.0-b0
JVM version = 1.9.0-b0 0.0.0-b0
----------System.err:(13/763)----------
java.lang.RuntimeException: Unmatched version: 1.9.0-b0 vs 0.0.0-b0
	at Version.main(Version.java:56)
Comments
I don't see an issue with it. b00 is expected.
06-10-2014
Shall we close it?
06-10-2014
Thanks, Stefan. Closing this bug, since it is fixed with full JDK builds.
06-10-2014
This is the output of a recent jprt build: java -version java version "1.9.0-internal" Java(TM) SE Runtime Environment (build 1.9.0-internal-201410030842.anoll.JDK-8046266-b00) Java HotSpot(TM) 64-Bit Server VM (build 1.9.0-internal-201410030842.anoll.JDK-8046266-b00, mixed mode) Is this what it is expected to be
03-10-2014
Albert, please verify.
02-10-2014
Do JPRT test build of whole forest (-testset hotspot) and run this test with it. It could be we do have bug in Hotspot makefiles.
09-09-2014
"might" or "will"?
08-09-2014
On Solaris, the following set of options are used to compile vm_version.cpp CC -DSOLARIS -DSPARC_WORKS -DAMD64 -DASSERT -DCHECK_UNHANDLED_OOPS -I/export/anoll/JDK-8046266/src/share/vm/prims -I/export/anoll/JDK-8046266/src/share/vm -I/export/anoll/JDK-8046266/src/share/vm/precompiled -I/export/anoll/JDK-8046266/src/cpu/x86/vm -I/export/anoll/JDK-8046266/src/os_cpu/solaris_x86/vm -I/export/anoll/JDK-8046266/src/os/solaris/vm -I/export/anoll/JDK-8046266/src/os/posix/vm -I../generated -DHOTSPOT_BUILD_USER="\"anoll\"" -DHOTSPOT_LIB_ARCH=\"amd64\" -DHOTSPOT_VM_DISTRO="\"OpenJDK\"" -DHOTSPOT_RELEASE_VERSION="\"1.9.0-fastdebug-internal\"" -DJRE_RELEASE_VERSION="\"1.9.0-fastdebug\"" -DJDK_MAJOR_VERSION="\"\"" -DJDK_MINOR_VERSION="\"\"" -DJDK_MICRO_VERSION="\"\"" -DJDK_BUILD_NUMBER="\"\"" -DTARGET_OS_FAMILY_solaris -DTARGET_ARCH_x86 -DTARGET_ARCH_MODEL_x86_64 -DTARGET_OS_ARCH_solaris_x86 -DTARGET_OS_ARCH_MODEL_solaris_x86_64 -DTARGET_COMPILER_sparcWorks -DCOMPILER2 -DCOMPILER1 -DDONT_USE_PRECOMPILED_HEADER -m64 -m64 /export/anoll/JDK-8046266/src/os_cpu/solaris_x86/vm/solaris_x86_64.il -template=no%extdef -features=no%split_init -D_Crun_inline_placement -library=%none -KPIC -mt -xdebugformat=stabs -xO4 -g0 -xs -g0 -xs -DVM_LITTLE_ENDIAN -xwe -features=no%except -DHAVE_DTRACE_H -c -xMMD -xMF ../generated/dependencies/vm_version.o.d -o vm_version.o /export/anoll/JDK-8046266/src/share/vm/runtime/vm_version.cpp sh /export/anoll/JDK-8046266/make/solaris/makefiles/build_vm_def.sh *.o > vm.def The interesting options are: -DJDK_MAJOR_VERSION="\"\"" -DJDK_MINOR_VERSION="\"\"" -DJDK_MICRO_VERSION="\"\"" -DJDK_BUILD_NUMBER="\"\"" Could this be the reason for the wrong output of the version string? On Linux (where the test passes), we use the following options to compile vm_version.cpp g++ -DLINUX -D_GNU_SOURCE -DAMD64 -DASSERT -DCHECK_UNHANDLED_OOPS -I/export/anoll/JDK-8046266/src/closed/share/vm/prims -I/export/anoll/JDK-8046266/src/share/vm/prims -I/export/anoll/JDK-8046266/src/closed/share/vm -I/export/anoll/JDK-8046266/src/share/vm -I/export/anoll/JDK-8046266/src/share/vm/precompiled -I/export/anoll/JDK-8046266/src/closed/cpu/x86/vm -I/export/anoll/JDK-8046266/src/cpu/x86/vm -I/export/anoll/JDK-8046266/src/os_cpu/linux_x86/vm -I/export/anoll/JDK-8046266/src/closed/os/linux/vm -I/export/anoll/JDK-8046266/src/os/linux/vm -I/export/anoll/JDK-8046266/src/closed/os/posix/vm -I/export/anoll/JDK-8046266/src/os/posix/vm -I../generated -DHOTSPOT_BUILD_USER="\"anoll\"" -DHOTSPOT_LIB_ARCH=\"amd64\" -DHOTSPOT_VM_DISTRO="\"Java HotSpot(TM)\"" -DHOTSPOT_RELEASE_VERSION="\"1.9.0-fastdebug-internal\"" -DJRE_RELEASE_VERSION="\"1.9.0-fastdebug\"" -DJDK_MAJOR_VERSION="\"1\"" -DJDK_MINOR_VERSION="\"9\"" -DJDK_MICRO_VERSION="\"0\"" -DJDK_BUILD_NUMBER="\"0\"" -DTARGET_OS_FAMILY_linux -DTARGET_ARCH_x86 -DTARGET_ARCH_MODEL_x86_64 -DTARGET_OS_ARCH_linux_x86 -DTARGET_OS_ARCH_MODEL_linux_x86_64 -DTARGET_COMPILER_gcc -DCOMPILER2 -DCOMPILER1 -DDONT_USE_PRECOMPILED_HEADER -fPIC -fno-rtti -fno-exceptions -D_REENTRANT -fcheck-new -fvisibility=hidden -m64 -pipe -fno-strict-aliasing -g -fno-omit-frame-pointer -O3 -O0 -fstack-protector-all --param ssp-buffer-size=1 -DVM_LITTLE_ENDIAN -D_LP64=1 -Werror -Wpointer-arith -Wsign-compare -Wundef -Wunused-function -Wunused-value -Wformat=2 -c -MMD -MP -MF ../generated/dependencies/vm_version.o.d -fpch-deps -o vm_version.o /export/anoll/JDK-8046266/src/share/vm/runtime/vm_version.cpp The interesting options are: -DJDK_MAJOR_VERSION="\"1\"" -DJDK_MINOR_VERSION="\"9\"" -DJDK_MICRO_VERSION="\"0\"" -DJDK_BUILD_NUMBER="\"0\""
02-09-2014
[~anoll] Albert, Please, investigate this, Pavel could be right. Look what JVM_GetVersionInfo() in jvm.cpp returns. Thanks, Vladimir
27-08-2014
Hi Vladimir, It looks like for this particular case of build (the one you called "Local Hotspot JVM build") the following set of fields of sun.misc.Version either are not set or set with zeroes: jvm_major_version jvm_minor_version jvm_micro_version jvm_update_version jvm_build_number These fields are supposed to be set as a result of call to native sun.misc.Version.getJvmVersionInfo. The methods returns true upon its call and nevertheless fields are zeroes. Vladimir, could you please help me to understand what is going on here from the native perspective? Thanks. -Pavel
27-08-2014
JDK_BUILD_NUMBER is defined by the build system. See jvm.h: /* Build number is available only for RE build (i.e. JDK_BUILD_NUMBER is set to bNN) * It will be zero for internal builds. */
15-08-2014
Vladimir, Christian, may I see the specification for the contents of System.getProperty("java.vm.version") for different kind of builds? For instance, when comparing these: 1.9.0-ea-fastdebug-b22 1.9.0-fastdebug-internal-201407111616.amurillo.jdk9-hs-2014-07-11 where exactly sun.misc.Version.jdk_build_number is encoded? (in this case "b22").
14-08-2014
When are we fixing this problem? It fails since more than 2 months straight.
14-08-2014
Note, the problem happens only with locally build JVM (by engineer or in JPRT). We use Hotspot JVM build by JPRT for Nightly testing where this test fails: $ java -version java version "1.9.0-ea-fastdebug" Java(TM) SE Runtime Environment (build 1.9.0-ea-fastdebug-b22) Java HotSpot(TM) 64-Bit Server VM (build 1.9.0-fastdebug-internal-201407111616.amurillo.jdk9-hs-2014-07-11, mixed mode) $ java Version newVersionInfo: input=1.9.0-ea-fastdebug-b22 output=1.9.0-b22 JDK version = 1.9.0-b22 1.9.0-b22 newVersionInfo: input=1.9.0-fastdebug-internal-201407111616.amurillo.jdk9-hs-2014-07-11 output=1.9.0-b0 JVM version = 1.9.0-b0 0.0.0-b0 Exception in thread "main" java.lang.RuntimeException: Unmatched version: 1.9.0-b0 vs 0.0.0-b0 at Version.main(Version.java:56) Local Hotspot JVM build: $ java -version java version "1.9.0-ea-fastdebug" Java(TM) SE Runtime Environment (build 1.9.0-ea-fastdebug-b22) Java HotSpot(TM) 64-Bit Server VM (build 1.9.0-debug-internal, mixed mode) $ java Version newVersionInfo: input=1.9.0-ea-fastdebug-b22 output=1.9.0-b22 JDK version = 1.9.0-b22 1.9.0-b22 newVersionInfo: input=1.9.0-debug-internal output=1.9.0-b0 JVM version = 1.9.0-b0 0.0.0-b0 Exception in thread "main" java.lang.RuntimeException: Unmatched version: 1.9.0-b0 vs 0.0.0-b0 at Version.main(Version.java:56) Promoted builds works fine but it does not help to our testing: $ java -version java version "1.9.0-ea-fastdebug" Java(TM) SE Runtime Environment (build 1.9.0-ea-fastdebug-b22) Java HotSpot(TM) 64-Bit Server VM (build 1.9.0-ea-fastdebug-b22-fastdebug, mixed mode) $ java Version newVersionInfo: input=1.9.0-ea-fastdebug-b22 output=1.9.0-b22 JDK version = 1.9.0-b22 1.9.0-b22 newVersionInfo: input=1.9.0-ea-fastdebug-b22-fastdebug output=1.9.0-b22 JVM version = 1.9.0-b22 1.9.0-b22
11-07-2014
Vladimir, could you please attach a file with the output from the test? (jira corrupts the text in the description)
16-06-2014
RULE sun/misc/Version/Version.java Exception java.lang.RuntimeException: Unmatched version: ...-b0 vs ...-b0
06-06-2014