Regression in test sun/misc/Version/Version.java with 8u262-b01

[Andrew Brygin]

The root cause of the problem is that jdk_version_info and
jvm_version_info structures store the update number in 8bit fields.

262 is 0x106, so now the update number does not fit the fields capacity,
and after truncation we see update number 6 instead of 262.

Note that the same problem exists in openjdk7 starting January 2020.

Thanks,
Andrew

On 06/05/2020 17:02, Severin Gehwolf wrote:
> Hi,
> 
> This is a heads-up that jtreg test sun/misc/Version/Version.java is
> failing since 8u262-b01 (worked last with 8u252 batch). Failure looks
> like this:
> 
> jdkVersionInfo: input=1.8.0_262-ea-b01 output=1.8.0_262-b1
> JDK version = 1.8.0_262-b1  1.8.0_6-b1
> ----------System.err:(13/788)----------
> java.lang.RuntimeException: Unmatched version: 1.8.0_262-b1 vs 1.8.0_6-b1
>         at Version.main(Version.java:47)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>         at java.lang.reflect.Method.invoke(Method.java:498)
>         at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>         at java.lang.Thread.run(Thread.java:748)
> 
> The issue is that sun.misc.Version.jdkUpdateVersion() returns '6' rather than '262'.
> 
> I'm looking into it.
> 
> Thanks,
> Severin
>