JDK-8076568 : vm/gc/compact/Humongous_Arrays Crash EXCEPTION_ACCESS_VIOLATION
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 8u60,9
  • Priority: P2
  • Status: Resolved
  • Resolution: Duplicate
  • Submitted: 2015-04-02
  • Updated: 2015-05-18
  • Resolved: 2015-05-18
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 8 JDK 9
8u60Resolved 9Resolved
Related Reports
Blocks :  
JDK-8077383 - Re-enable eager reclaim by default
Duplicate :  
JDK-8069367 - Eagerly reclaimed humongous objects left on mark stack
Relates :  
JDK-8069367 - Eagerly reclaimed humongous objects left on mark stack
Description
could be a dup of JDK-8069367

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x710df3cd, pid=230944, tid=189692
#
# JRE version: Java(TM) SE Runtime Environment (9.0-b56) (build 1.9.0-ea-b56)
# Java VM: Java HotSpot(TM) Server VM (1.9.0-ea-b56 compiled mode windows-x86 )
# Problematic frame:
# V  [jvm.dll+0x28f3cd]
#
# Core dump written. Default location: C:\local\aurora\sandbox\results\ResultDir\Humongous_Arrays\hs_err_pid230944.mdmp
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
#

---------------  T H R E A D  ---------------

Current thread (0x00f17800):  ConcurrentGCThread [stack: 0x3ef30000,0x3ef80000] [id=189692]

siginfo: ExceptionCode=0xc0000005, reading address 0x00000004

Registers:
EAX=0x00000001, EBX=0x00000000, ECX=0x00000000, EDX=0x0000002e
ESP=0x3ef7f504, EBP=0x3ef7f50c, ESI=0x12800000, EDI=0x00f56a48
EIP=0x710df3cd, EFLAGS=0x00010202

Top of Stack: (sp=0x3ef7f504)
0x3ef7f504:   00000000 00f56a48 3ef7f520 710e007c
0x3ef7f514:   12800000 3e3b0000 00f56a48 3ef7f568
0x3ef7f524:   710e05ed 12800000 00edd740 3eeef95c
0x3ef7f534:   00f56a48 712f0334 00fabf98 712bbde4
0x3ef7f544:   3ef7f538 00ee9018 00eb40e0 00f56a48
0x3ef7f554:   712f032c 00ee909c 00ee9018 00f56a48
0x3ef7f564:   01ffead1 3ef7f5c0 710e0a02 00000000
0x3ef7f574:   40240000 00000001 00000000 00f17800 

Instructions: (pc=0x710df3cd)
0x710df3ad:   8b e5 5d c3 cc cc cc cc cc cc cc cc cc cc cc cc
0x710df3bd:   cc cc cc 55 8b ec 56 8b 75 08 57 8b f9 8b 4e 04
0x710df3cd:   8b 41 04 85 c0 7e 09 a8 01 75 32 c1 f8 02 eb 35
0x710df3dd:   79 2b 8b 15 04 a8 3b 71 8b c8 53 8b 5e 08 83 e1 


Register to memory mapping:

EAX=0x00000001 is an unknown value
EBX=0x00000000 is an unknown value
ECX=0x00000000 is an unknown value
EDX=0x0000002e is an unknown value
ESP=0x3ef7f504 is an unknown value
EBP=0x3ef7f50c is an unknown value
ESI=0x12800000 is pointing into object: 0x12700000
[C 
 - klass: {type array char}
 - length: 734001
EDI=0x00f56a48 is an unknown value


Stack: [0x3ef30000,0x3ef80000],  sp=0x3ef7f504,  free space=317k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [jvm.dll+0x28f3cd]
V  [jvm.dll+0x29007c]
V  [jvm.dll+0x2905ed]
V  [jvm.dll+0x290a02]
V  [jvm.dll+0x1c2d52]
V  [jvm.dll+0x1db4c1]
C  [msvcr100.dll+0x5c556]
C  [msvcr100.dll+0x5c600]
C  [KERNEL32.DLL+0x17c04]
C  [ntdll.dll+0x5b90f]
C  [ntdll.dll+0x5b8da]
Comments
Duplicate of JDK-8069367
18-05-2015
This appears to be a duplicate of either JDK-8069367 or JDK-8075215, both bugs in eager reclaim of humongous objects. The backtrace places us in CMTask::do_marking_step, where both sources of potentially stale humongous object pointers are processed. However, it's from a release build, so none of the assertions that would clarify exactly what happened are present. I'm not sure how to get from the reported PC to a source code line that would provide context. ESI contains 0x12800000, which is presently the start of a humongous_continues region that starts at 0x12700000. We could have gotten into this situation via the following sequence of events 1. A humongous object at 0x12800000 was eagerly reclaimed while a reference to it was present in either the mark stack / local mark buffers, or in a completed SATB buffer. 2. A new humongous object requiring two regions was allocated at 0x12700000. 3. Processing of the relevant buffer encountered the stale reference.
18-05-2015
Backtrace: 0 PC=0x7714d74c ntdll.dll+0x3d74c FAULT: 0xc0000005 at 0x710df3cd in thread 0x2e4fc saved context SP=0x3ef7f504 FP=0x3ef7f50c PC=0x710df3cd >1 PC=0x710df3cd jvm.dll+0x28f3cd public void CMTask::do_marking_step(double,bool)+0x5d 2 PC=0xf56a48 core 3 PC=0x710e007c jvm.dll+0x29007c public virtual void ConcurrentMarkThread::run(void)+0x1ec 4 PC=0x710e007c jvm.dll+0x29007c public virtual void ConcurrentMarkThread::run(void)+0x1ec 5 PC=0x12800000 core 6 PC=0x710e05ed jvm.dll+0x2905ed public void DirtyCardQueueSet::concatenate_logs(void)+0x2d 7 PC=0x710e05ed jvm.dll+0x2905ed public void DirtyCardQueueSet::concatenate_logs(void)+0x2d 8 PC=0x12800000 core 9 PC=0x710e0a02 jvm.dll+0x290a02 public void DirtyCardQueueSet::par_apply_closure_to_all_completed_buffers(CardTableEntryClosure*&)+0xf2
11-05-2015
ILW = High (crash), Low (happened once), High (none) = P2
08-04-2015