JDK-8042267 : DeadThreadInterrupted failed due to "fatal error: corrupted C heap"
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 9
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows_8
  • CPU: x86
  • Submitted: 2014-05-01
  • Updated: 2014-05-21
  • Resolved: 2014-05-21
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
Related Reports
Duplicate :  
JDK-8028749 - java -version crashes with 'fatal error: heap walk aborted with error 1'
Description
This failure was spotted in the 2014-04-30 RT_Baseline nightly:

runtime/threads/DeadThreadInterrupted

    This test failed due to:

    Internal Error (src\os\windows\vm\os_windows.cpp:5015), pid=45884, tid=45292
    fatal error: corrupted C heap

    with the following stack:

    V  [jvm.dll+0x2cebe2]  VMError::report_and_die+0x412;; ?report_and_die@VMError@@QAEXXZ+0x412
    V  [jvm.dll+0x2c38a6]  report_fatal+0x46;;  ?report_fatal@@YAXPBDH0@Z+0x46
    V  [jvm.dll+0x2efb28]  os::check_heap+0xe8;;  ?check_heap@os@@SA_N_N@Z+0xe8
    V  [jvm.dll+0x29565a]  VMThread::run+0x14a;;  ?run@VMThread@@UAEXXZ+0x14a
    V  [jvm.dll+0x2efcf1]  java_start+0xb1;;  ?java_start@@YGIPAVThread@@@Z+0xb1
Comments
I suspect this is caused by a failed call to HeapLock before walking the heap and we ended up walking the heap and validating a free'd chunk. The HeapLock issue has been fixed in JDK-8028749. Closing this issue as a dupe of JDK-8028749, if it ever shows up again we'll have to re-investigate this.
21-05-2014
Try to reproduce on the same machine and run memtest on the machine.
05-05-2014
Fails with: C heap has been corrupted (time: 1 allocations) corrupted block near address 0x87d768, length 32 Did not find any errors when examining the heap from the mdmp: 0:004> !heap -triage 0x87d768 ********************************************************** ** !heap: Searching for the heap and segment that ** contain the specified address. To search ** for the entry that contains this address, ** use !heap -x 0087d768. ********************************************************** ** !heap: Searching heap at 00850000... ** !heap: Found address in segment at 00850000, analyzing... ** !heap: Analyzing lists for heap at 00850000... ** !heap: Also found LFH for heap at 00850000, analyzing... ** !heap: The extension did not find any heap errors. 0:004> !heap -x 0x87d768 Entry User Heap Segment Size PrevSize Unused Flags ----------------------------------------------------------------------------- 0087d760 0087d768 00850000 008764b0 20 - 0 LFH;free 0:004> !heap -v 00850000 Index Address Name Debugging options enabled 1: 00850000 Segment at 00850000 to 0094f000 (00088000 bytes committed) Flags: 00000002 ForceFlags: 00000000 Granularity: 8 bytes Segment Reserve: 00100000 Segment Commit: 00002000 DeCommit Block Thres: 00000800 DeCommit Total Thres: 00002000 Total Free Size: 000076c0 Max. Allocation Size: 7ffdefff Lock Variable at: 00850248 Next TagIndex: 0000 Maximum TagIndex: 0000 Tag Entries: 00000000 PsuedoTag Entries: 00000000 Virtual Alloc List: 0085009c Uncommitted ranges: 0085008c FreeList[ 00 ] at 008500c0: 0087e338 . 008676b8 (13 blocks) wFlags in the PROCESS_HEAP_ENTRY structure seems to be set to BUSY: 0:004> dw 3424f3c4+0xa l1 3424f3ce 0004 at least when we got it from HeapWalk Did not manage to reproduce this when running the test locally with and without heap gflags.
01-05-2014