Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8009634

TEST_BUG: sun/misc/Version/Version.java handle 2 digit minor in VM version

    Details

    • Subcomponent:
    • Introduced In Build:
      b05
    • Introduced In Version:
    • Resolved In Build:
      b02
    • CPU:
      generic
    • OS:
      generic
    • Verification:
      Verified

      Backports

        Description

        Testsuite name: Regression
        Test name: sun/misc/Version/Version.java
        JDK tested: jdk 7u21 b05
        OS tested: Windows
        Is it a regression: YES
        Regression introduced in: 7u21 b05

        LOG:

        #section:main
        ----------messages:(3/103)----------
        command: main Version
        reason: User specified action: run main Version
        elapsed time (seconds): 0.61
        ----------System.out:(4/181)----------
        newVersionInfo: input=1.7.0_21-b05 output=1.7.0_21-b5
        JDK version = 1.7.0_21-b5 1.7.0_21-b5
        newVersionInfo: input=23.21-b01 output=23.2.0-b0
        JVM version = 23.2.0-b0 23.21.0-b1
        ----------System.err:(13/785)----------
        java.lang.RuntimeException: Unmatched version: 23.2.0-b0 vs 23.21.0-b1
        at Version.main(Version.java:56)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:601)
        at com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:96)
        at java.lang.Thread.run(Thread.java:722)

        JavaTest Message: Test threw exception: java.lang.RuntimeException: Unmatched version: 23.2.0-b0 vs 23.21.0-b1
        JavaTest Message: shutting down test

        STATUS:Failed.`main' threw exception: java.lang.RuntimeException: Unmatched version: 23.2.0-b0 vs 23.21.0-b1
        result: Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: Unmatched version: 23.2.0-b0 vs 23.21.0-b1


        test result: Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: Unmatched version: 23.2.0-b0 vs 23.21.0-b1

          Issue Links

            Activity

            Hide
            kshefov Konstantin Shefov added a comment -
            It seems somebody forgot to change version number.
            Show
            kshefov Konstantin Shefov added a comment - It seems somebody forgot to change version number.
            Hide
            dcubed Daniel Daugherty added a comment -
            Take a close look at this output from the test:

            ----------System.out:(4/181)----------
            newVersionInfo: input=1.7.0_21-b05 output=1.7.0_21-b5
            JDK version = 1.7.0_21-b5 1.7.0_21-b5
            newVersionInfo: input=23.21-b01 output=23.2.0-b0
            JVM version = 23.2.0-b0 23.21.0-b1

            The JVM input of "23.21-b01" is morphed into "23.2.0-b0" which is clearly wrong
            so the comparison of "23.2.0-b0" and "23.21.0-b1" don't match.
            Show
            dcubed Daniel Daugherty added a comment - Take a close look at this output from the test: ----------System.out:(4/181)---------- newVersionInfo: input=1.7.0_21-b05 output=1.7.0_21-b5 JDK version = 1.7.0_21-b5 1.7.0_21-b5 newVersionInfo: input=23.21-b01 output=23.2.0-b0 JVM version = 23.2.0-b0 23.21.0-b1 The JVM input of "23.21-b01" is morphed into "23.2.0-b0" which is clearly wrong so the comparison of "23.2.0-b0" and "23.21.0-b1" don't match.
            Hide
            coffeys Sean Coffey added a comment -
            hsx version for 7u21 was updated to 23.21-b01 (new system for 7u where hsx minor version matches JDK update version)
            Show
            coffeys Sean Coffey added a comment - hsx version for 7u21 was updated to 23.21-b01 (new system for 7u where hsx minor version matches JDK update version)
            Hide
            amurillo Alejandro Murillo (Inactive) added a comment -
            I took a look at the JVM version parsing code in Version.java and it expects the hotspot version to be nn.n:
                            // HSX has nn.n (major.minor) version
                            major = Integer.valueOf(version.substring(0, 2)).intValue();
                            minor = Character.digit(cs.charAt(3), 10);
                            cs = cs.subSequence(4, cs.length());

            It can't handle 21, I guess we never had a 2 digit minor version for hotspot.
            This is not a hotspot/build bug.
            Show
            amurillo Alejandro Murillo (Inactive) added a comment - I took a look at the JVM version parsing code in Version.java and it expects the hotspot version to be nn.n:                 // HSX has nn.n (major.minor) version                 major = Integer.valueOf(version.substring(0, 2)).intValue();                 minor = Character.digit(cs.charAt(3), 10);                 cs = cs.subSequence(4, cs.length()); It can't handle 21, I guess we never had a 2 digit minor version for hotspot. This is not a hotspot/build bug.
            Hide
            dholmes David Holmes added a comment -
            Similar to the problem we had when we first hit a three-digit build number.
            Show
            dholmes David Holmes added a comment - Similar to the problem we had when we first hit a three-digit build number.
            Hide
            dholmes David Holmes added a comment -
            Seems wrong that sun.misc isn't a core-libs category. Don't know who will see this in other-libs/other
            Show
            dholmes David Holmes added a comment - Seems wrong that sun.misc isn't a core-libs category. Don't know who will see this in other-libs/other
            Hide
            alanb Alan Bateman added a comment - - edited
            I've moved this to core-libs/java.lang for now and Rob has agreed to take it and fix the test.

            Note that this is not a regression, it's just that the test needs to be updated to take account of the new version syntax.
            Show
            alanb Alan Bateman added a comment - - edited I've moved this to core-libs/java.lang for now and Rob has agreed to take it and fix the test. Note that this is not a regression, it's just that the test needs to be updated to take account of the new version syntax.
            Hide
            kvn Vladimir Kozlov added a comment - - edited
            Did you test the fix with internal VM builds? For example, from JPRT builds which are used for Hotspot testing:

            24.0-b37-internal-201303141810.amurillo.hs24-b37-set-ver-fastdebug

            Note, the official Hotspot VM version string is defined in hotspot/src/share/vm/runtime/vm_version.cpp :

            <major_ver>.<minor_ver>-b<nn>[-<identifier>][-<debug_target>]

            Build number always follows major.minor numbers.
            And identifier can be any string, for example in this case: internal-201303141810.amurillo.hs24-b37-set-ver

            Thanks,
            Vladimir
            Show
            kvn Vladimir Kozlov added a comment - - edited Did you test the fix with internal VM builds? For example, from JPRT builds which are used for Hotspot testing: 24.0-b37-internal-201303141810.amurillo.hs24-b37-set-ver-fastdebug Note, the official Hotspot VM version string is defined in hotspot/src/share/vm/runtime/vm_version.cpp : <major_ver>.<minor_ver>-b<nn>[-<identifier>][-<debug_target>] Build number always follows major.minor numbers. And identifier can be any string, for example in this case: internal-201303141810.amurillo.hs24-b37-set-ver Thanks, Vladimir
            Hide
            robm Robert Mckenna added a comment -
            No, unfortunately. I wrote the regex to correspond to the description in the testcase:

            n.n.n[_uu[c]][-<identifer>]-bxx. I had mistakenly interpreted the description to mean that identifier could only be a set word.

            Won't the above string trick the original to use the 2nd b37 though? I.e. if the string was 24.0-b37-internal-201303141810.amurillo.hs24-b38-set-ver-fastdebug the build would be reported incorrectly? (just making sure I understand how to interpret this for my follow up)
            Show
            robm Robert Mckenna added a comment - No, unfortunately. I wrote the regex to correspond to the description in the testcase: n.n.n[_uu[c]][-<identifer>]-bxx. I had mistakenly interpreted the description to mean that identifier could only be a set word. Won't the above string trick the original to use the 2nd b37 though? I.e. if the string was 24.0-b37-internal-201303141810.amurillo.hs24-b38-set-ver-fastdebug the build would be reported incorrectly? (just making sure I understand how to interpret this for my follow up)

              People

              • Assignee:
                robm Robert Mckenna
                Reporter:
                kshefov Konstantin Shefov
              • Votes:
                0 Vote for this issue
                Watchers:
                11 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: