code review round 1 for JDK-8028749 java -version crashes with 'fatal error: heap walk aborted with error 1'
Ron Durbin
ron.durbin at oracle.com
Wed May 14 17:24:36 UTC 2014
Thanks Dan
> -----Original Message-----
> From: Daniel D. Daugherty
> Sent: Wednesday, May 14, 2014 10:56 AM
> To: Ron Durbin
> Cc: hotspot-runtime-dev at openjdk.java.net
> Subject: Re: code review round 1 for JDK-8028749 java -version crashes with 'fatal error:
> heap walk aborted with error 1'
>
> > http://cr.openjdk.java.net/~rdurbin/JDK-8028749-webrev-cr1
>
> src/os/windows/vm/os_windows.cpp
> No comments.
>
> Thumbs up.
>
> Dan
>
>
> On 5/13/14 9:10 PM, Ron Durbin wrote:
> > Greetings,
> >
> > This fix was revised after the initial round of code review.
> > The code and the invite have been revised.
> >
> > This fix resolves:
> >
> > JDK-8028749 java -version crashes with
> > 'fatal error: heap walk aborted with error 1'
> >
> > Summary:
> > When traversing the C Heap in the Windows OS the heap lock must
> > held. If HeapWalk() is called to walk the heap without holding the
> > lock it can fail. If HeapLock() is called to lock the heap it can fail if
> > heap checking like windows gflags.exe is enabled. Failure to check
> > the return status of HeapLock() can result HeapWalk failing to
> > traverse the heap.
> >
> > The call to HeapLock() return status is now checked and if the status
> > indicates a failure the heap checking is skipped.
> >
> > You will find the webrev by following the URL below.
> >
> > http://cr.openjdk.java.net/~rdurbin/JDK-8028749-webrev-cr1
> >
> >
> >> -----Original Message-----
> >> From: Ron Durbin
> >> Sent: Friday, May 02, 2014 12:08 PM
> >> To: hotspot-runtime-dev at openjdk.java.net
> >> Cc: Ron Durbin
> >> Subject: code review round 0 for JDK-8028749 java -version crashes with 'fatal error:
> heap
> >> walk aborted with error 1'
> >>
> >> Greetings,
> >>
> >> This fix resolves:
> >>
> >> JDK-8028749 java -version crashes with
> >> 'fatal error: heap walk aborted with error 1'
> >>
> >> Summary:
> >> When the gflags are enabled it appears that Windows does not
> >> support application heap checking. This fix disables part of the
> >> JVM heap check based on the Windows HeapWalk() API when certain
> >> gflags checks are enabled.
> >>
> >> Testing:
> >> These code changes have tested by completing a successful HotSpot build
> >> with windows heap checks turned on and off.
> >> The heap check manipulation was done via gflages.exe
> >> with a reboot following each change before each test run.
> >>
> >> The success criteria was a successfully completed build without
> >> the java command crashing and leaving a mini dump.
> >> This fix disables part of the JVM heap check based on the Windows
> >> HeapWalk() API when certain gflags checks are enabled.
> >>
> >> You will find the webrev by following the URL below.
> >>
> >> http://cr.openjdk.java.net/~rdurbin/JDK-8028749-webrev/0-jdk9-hs-runtime/
>
More information about the hotspot-runtime-dev
mailing list