JDK-8028749 : java -version crashes with 'fatal error: heap walk aborted with error 1'
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: hs25
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_7
  • CPU: x86_64
  • Submitted: 2013-11-21
  • Updated: 2016-03-14
  • Resolved: 2014-05-15
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 9
9 b15Fixed
Related Reports
Duplicate :  
JDK-8042267 - DeadThreadInterrupted failed due to "fatal error: corrupted C heap"
Relates :  
JDK-8147481 - VM crash fatal error: corrupted C heap (runtime.threads.Threads2a.Threads2a)
Relates :  
JDK-8143233 - [windows] Fixes to os::check_heap()
Relates :  
JDK-8151805 - fatal error: heap walk aborted with error 1
Description
Observed the following failure of "java -version" with current fastdebug Main_baseline bits on a Win7-64 machine:


     Test invocation of VM library with -version option:
/cygdrive/d/JAVA_BUG/HS_BLD_TEST_MAIN/BASE/dest_jdk/bin/java
-server_BASE_rdurbin-fast -d64 -version
     java version "1.8.0-ea"
     Java(TM) SE Runtime Environment (build 1.8.0-ea-b116)
     Java HotSpot(TM) 64-Bit Server VM (build 25.0-b60-BASE_rdurbin-fastdebug, mixed mode)
     # To suppress the following error report, specify this argument
     # after -XX: or in .hotspotrc: SuppressErrorAt=\os_windows.cpp:5016
     #
     # A fatal error has been detected by the Java Runtime Environment:
     #
     #  Internal Error
(D:\JAVA_BUG\HS_BLD_TEST_MAIN\BASE\repos\src\os\windows\vm\os_windows.cpp:5016),
pid=6084, tid=4668
     #  fatal error: heap walk aborted with error 1
     #
     # JRE version: Java(TM) SE Runtime Environment (8.0-b116) (build
1.8.0-ea-b116)
     # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.0-b60-BASE_rdurbin-fastdebug mixed mode windows-amd64 compressed oops)
     # Core dump written. Default location: 
D:\JAVA_BUG\HS_BLD_TEST_MAIN\BASE\hs_err_pid6084.mdmp
     #
     # An error report file with more information is saved as:
     # D:\JAVA_BUG\HS_BLD_TEST_MAIN\BASE\hs_err_pid6084.log
     #
     # If you would like to submit a bug report, please visit:
     #   http://bugreport.sun.com/bugreport/crash.jsp
     #
     Java HotSpot(TM) 64-Bit Server VM (25.0-b60-BASE_rdurbin-fastdebug) for windows-amd64 JRE (1.8.0), built on Nov 20 2013 22:06:54 by "rdurbin" with MS VC++ 10.0 (VS2010)

     Build windows_amd64_compiler2/fastdebug time: 2.93 minutes.

See the attached hs_err_pid file.

The scenario:

- clone Main_Baseline to base_repo
- clone base_repo exp_repo
- execute parallel fastdebug builds in both repos
- one of the builds should fail with the above
Comments
Dan I agree with your comment. Your approach would make sure that the ERROR_INVALID_FUNCTION was a result of the HeapWalk() call.
11-12-2013
In non-product bits, the VM does some sanity checking at VM exit time. One of those sanity checks includes a call to os::check_heap() before calling Universe::verify(). The os::check_heap() function uses the Windows HeapWalk() API. When "gflags.exe /p /enable java.exe /full" is run, the AppVerifier is enabled and that causes the HeapWalk() function to fail with ERROR_INVALID_FUNCTION. The AppVerifier may not be the only gflags setting that causes the HeapWalk() API to fail. See the following URL for more info: https://groups.google.com/forum/#!msg/microsoft.public.win32.programmer.tools/6tpw5UP7CD4/O5IOdQvY82MJ
11-12-2013
I would be OK with the "err != ERROR_INVALID_FUNCTION" check if it was restricted to the first HeapWalk() call. Where it is currently placed, it applies to any Windows system call that fails.
11-12-2013
Since the Windows debug code is doing the heap corruption verification for us when gflags is set and HeapWalk() returns ERROR_INVALID_FUNCTION could we add an additional condition to the if statement in os_windows.cpp:os::check_heap() so the VM does not crash? Something like this: DWORD err = GetLastError(); if (err != ERROR_NO_MORE_ITEMS && err != ERROR_CALL_NOT_IMPLEMENTED && err != ERROR_INVALID_FUNCTION) { fatal(err_msg("heap walk aborted with error %d", err)); }
11-12-2013
Given the new information, the new ILW is: ILW: HLL -> P4 I: High, crashing L: low, "only seen on one developer's laptop and only if certain Windows diagnostics settings are applied" W: L, turn diagnostic setting off for workaround Deferral OK by SQE
04-12-2013
The issue has only been seen on one developer's laptop and only if certain Windows diagnostics settings are applied, thus the likelihood is quite low. Investigation will continue, but requesting deferral from JDK8 to a possible JDK 8 update release.
04-12-2013
Does this happen during the build or when running the JVM after the build is done? Could you also make sure that you've turned off all gflag options for java.exe. If you could zip the mdmp and attach it to the bug it would be very useful.
22-11-2013
ILW HMM = P2 I: High, Crashing L: Medium, Reproducable W: Medium, Only seems to manifest with parallel builds
22-11-2013