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

[Andrew Brygin]

Hello Severin,

 thanks for creating the bug.

 Just a minor question regarding the proposed change for
 jdk_version_info: shall we reduce the size of reserved1 field from 16
 to 8 in order to preserve the size of the whole structure?

Thanks,
Andrew

On 07/05/2020 13:20, Severin Gehwolf wrote:
> 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
>