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

[Severin Gehwolf]

Hi Andrew,

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.

Thanks for this. That's right.

(gdb) 
100	    info->update_version = jdk_update_version;
(gdb) p jdk_update_version
$8 = 262
(gdb) p info->update_version
$10 = 6

Since 2^8-1 = 255 > 252 we start to see this issue with the 262 update
cycle.

Thanks,
Severin

> 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
> >