RFR: 8233785: Incorrect JDK version is reported in hs_err log
Thomas Stüfe
thomas.stuefe at gmail.com
Tue Nov 12 20:15:38 UTC 2019
Hi Yasumasa,
looks good. Could you please add a small comment mentioning JEP 223? E.g.
just a simple "/* See JEP 223 */"
I do not need to see another webrev.
Thanks, Thomas
On Mon, Nov 11, 2019 at 3:07 PM Yasumasa Suenaga <suenaga at oss.nttdata.com>
wrote:
> Thanks David!
> I wait second reviewer.
>
> Yasumasa
>
> On 2019/11/11 19:28, David Holmes wrote:
> > Sorry for the delay.
> >
> > Just confirming I've verified against the spec from JEP 223 and this fix
> is correct.
> >
> > Thanks,
> > David
> >
> > On 7/11/2019 10:39 pm, David Holmes wrote:
> >> Hi Yasumasa,
> >>
> >> On 7/11/2019 10:28 pm, Yasumasa Suenaga wrote:
> >>> Hi all,
> >>>
> >>> Please review this change:
> >>>
> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8233785
> >>> webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8233785/webrev.00/
> >>>
> >>> If JVM which is configured with --with-version-patch is crashed, JDK
> version in he_err log is incorrect.
> >>> We can get hs_err log which contains the following in header when we
> configure configure with "--with-version-update=0 --with-version-patch=1":
> >>>
> >>> ```
> >>> # JRE version: OpenJDK Runtime Environment (14.0.1+2) (build
> 14.0.0.1+2-TypeS)
> >>> ```
> >>>
> >>> Valid JDK version is "14.0.0.1", however it includes "14.0.1".
> >>> It is a bug in JDK_Version::to_string().
> >>
> >> I initially missed the fact that you always print _security along with
> _patch.
> >>
> >> I think what you have looks correct, but I'd want to double check that
> against the versioning spec to be sure.
> >>
> >> Thanks,
> >> David
> >>
> >>>
> >>> Thanks,
> >>>
> >>> Yasumasa
>
More information about the hotspot-runtime-dev
mailing list