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

[Severin Gehwolf]

Hi,

On Wed, 2020-05-06 at 17:31 +0300, Andrew Brygin wrote:
> 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.

I've created this bug to track this:
https://bugs.openjdk.java.net/browse/JDK-8244548

Thanks,
Severin