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

Daniel D. Daugherty daniel.daugherty at oracle.com
Fri May 2 19:48:16 UTC 2014


On 5/2/14 12:08 PM, Ron Durbin wrote:
> 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/

src/os/windows/vm/os_windows.cpp
     I think I see a flaw in the logic and you were right all along...
     Sorry I didn't see this when you did the whiteboard talk on Tues.

     Consider if this:

     line 5020: DWORD err = GetLastError();

     returns a value ERROR_FOO. In the old logic, we would always
     call fatal() on line 5020:

     line 5019: if (err != ERROR_NO_MORE_ITEMS && err != 
ERROR_CALL_NOT_IMPLEMENTED) {
     line 5020:   fatal(err_msg("heap walk aborted with error %d", err));

     In the new logic, we no longer call fatal() with a value of ERROR_FOO:

     line 5027:  if (err != ERROR_NO_MORE_ITEMS &&
     line 5028:      err != ERROR_CALL_NOT_IMPLEMENTED &&
     line 5029:      (did_first_heapwalk_call && err == 
ERROR_INVALID_FUNCTION)) {
     line 5030:    fatal(err_msg("heap walk aborted with error %d", err));

     The logic phrases on lines 5027 and 5028 are both still true with
     a value of ERROR_FOO, but the logic phrase on line 5030 will never
     be true with a value of ERROR_FOO.

     On Tuesday, you said we should put the new check inside the existing
     if-statment and you were right. Jerry and I were both wrong. Sigh...

     So this should do it:

     line 5027: if (err != ERROR_NO_MORE_ITEMS && err != 
ERROR_CALL_NOT_IMPLEMENTED) {
line 5028:   if (!did_first_heapwalk_call && err == 
ERROR_INVALID_FUNCTION) {
line 5029:     // only ignore this error on first HeapWalk() call
line 5030:   } else {
line 5031:     fatal(err_msg("heap walk aborted with error %d", err));
line 5032:   }
line 5033: }

     An ERROR_FOO value will always fail the logic phrase on line 5028
     so it will always call fatal on line 5031. ERROR_INVALID_FUNCTION
     only gets a pass on the first call to HeapWalk().

     It's ugly, but it's the only way I see to avoid duplicating the
     fatal() line.

Dan



More information about the hotspot-runtime-dev mailing list