code review round 1 for JDK-8028749 java -version crashes with 'fatal error: heap walk aborted with error 1'
Daniel D. Daugherty
daniel.daugherty at oracle.com
Wed May 14 16:55:52 UTC 2014
> 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