code review round 0 for JDK-8028749 java -version crashes with 'fatal error: heap walk aborted with error 1'

Christian Tornqvist christian.tornqvist at oracle.com
Tue May 6 13:50:01 UTC 2014


Hi Ron,

I think a better solution would be to call HeapQueryInformation() before
trying to walk the heap. The heap returned from GetProcessHeap() is not a
correct heap when heap debugging flags are turned on (for some reason).
Calling HeapQueryInformation() on an invalid heap will return false and then
we can skip trying to walk it.

Thanks,
Christian


-----Original Message-----
From: hotspot-runtime-dev
[mailto:hotspot-runtime-dev-bounces at openjdk.java.net] On Behalf Of Ron
Durbin
Sent: Friday, May 2, 2014 2:08 PM
To: hotspot-runtime-dev at openjdk.java.net
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