Bug ID: JDK-8069282 Corrupted C heap in jit/graph/cgt2

Versions (Unresolved/Resolved/Fixed)

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
9Resolved

The hs_err says "Warning: This error log is *not* generated by the following JVM" with a link to the tested VM. The log shows some test activity. Could it be some "stable" VM used to run the test framework that has problems?

Stack:
V  [jvm.dll+0x2e5015]  VMError::report_and_die+0x3d5;;  ?report_and_die@VMError@@QAEXXZ+0x3d5
V  [jvm.dll+0x2d8cb6]  report_fatal+0x46;;  ?report_fatal@@YAXPBDH0@Z+0x46
V  [jvm.dll+0x306fe2]  os::check_heap+0xf2;;  ?check_heap@os@@SA_N_N@Z+0xf2
V  [jvm.dll+0x2ad6eb]  VMThread::run+0x15b;;  ?run@VMThread@@UAEXXZ+0x15b
V  [jvm.dll+0x3093dc]  java_start+0xcc;;  ?java_start@@YGIPAVThread@@@Z+0xcc

Likely a Windows internal bug in HeapWalk/HeapValidate. Not a HotSpot bug and no indication of actual heap error. See details in JDK-8147481.
02-02-2016
Could we be seeing a problem because the code is checking the wrong heap as per JDK-8143233?
20-11-2015
As far as I can see, this duplicates JDK-8060145, even though the hs_err.log isn't broken in that case. This bug contains more info though and the other is already closed as CNR. There is only one occurrence of fatal("corrupted C heap"); in os_windows.cpp, so even though the line numbers differ between the five occurrences we see in these two bugs I think it's the same call that has moved around over time. I didn't look in detail, but there were several changes done to that file during December. To be honest I think five occurrences in the last couple of months are too many to close as CNR. Maybe we can add some logging or some additional information in the "corrupted C heap" message so that the next time it happens we know a little more? (JDK-8060145 duplicates two other bugs as well, so there are likely more than five occurrences of this problem.)
03-02-2015
Yes, there's an hs_err script that processes the hs_err_pid<pid>.log file. We needed this to get any stack traces before the code was added to print them out while printing out the hs_err_pid.log file. It also tries to decode the assembly at the crash on some platforms more successfully than on others.
03-02-2015
An MDMP file is available. Maybe our in-house expect with Windows could take a quick look. Assigned to [~ctornqvi]
03-02-2015
The address 0x11f61a0 doesn't match any ranges of the pointers in the hs_err file.
27-01-2015
Something from the log file that's may be semi-useful [2015-01-23T06:59:40.92] C heap has been corrupted (time: 1 allocations) [2015-01-23T06:59:40.92] corrupted block near address 0x11f61a0, length 8
26-01-2015
P4 I = High, crashes L = Low, difficult to reproduce W = Low, remove the check as it's not helping us to debug the vm.
26-01-2015
It was VM under test which failed to generate hs_err properly. Moving issue to runtime.
21-01-2015
I think we have a bug in the hs_err related code on windows as we see these "not generated" warnings a lot. The problem comes from: Actual vm_info: [] so we failed to retrieve the VM info.
20-01-2015

Duplicate :	JDK-8147481 - VM crash fatal error: corrupted C heap (runtime.threads.Threads2a.Threads2a)
Duplicate :	JDK-8058494 - nsk/stress/metaspace/jck60/jck60022 fails on windows with heap corruption
Relates :	JDK-8143249 - "fatal error: corrupted C heap" with '-XX:MallocVerifyInterval=1' option on win-64
Relates :	JDK-8147481 - VM crash fatal error: corrupted C heap (runtime.threads.Threads2a.Threads2a)