JDK-8130338 : ACCESS_VIOLATION in InstanceKlass::oop_ms_follow_contents()
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 9
  • Priority: P2
  • Status: Resolved
  • Resolution: Cannot Reproduce
  • OS: windows
  • CPU: x86
  • Submitted: 2015-07-02
  • Updated: 2017-02-10
  • Resolved: 2016-03-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.
Related Reports
Relates :  
Relates :  
Nightly failure:

Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [jvm.dll+0x48d9df]  InstanceKlass::oop_ms_follow_contents+0x3f;;  ?oop_ms_follow_contents@InstanceKlass@@UAEXPAVoopDesc@@@Z+0x3f
V  [jvm.dll+0x48d4c2]  MarkSweep::follow_stack+0xa2;;  ?follow_stack@MarkSweep@@SAXXZ+0xa2
V  [jvm.dll+0x27ca1c]  JavaThread::oops_do+0x6c;;  ?oops_do@JavaThread@@UAEXPAVOopClosure@@PAVCLDClosure@@PAVCodeBlobClosure@@@Z+0x6c
V  [jvm.dll+0x27d085]  Threads::possibly_parallel_oops_do+0x45;;  ?possibly_parallel_oops_do@Threads@@SAX_NPAVOopClosure@@PAVCLDClosure@@PAVCodeBlobClosure@@@Z+0x45
V  [jvm.dll+0x452582]  G1RootProcessor::process_strong_roots+0x62;;  ?process_strong_roots@G1RootProcessor@@QAEXPAVOopClosure@@PAVCLDClosure@@PAVCodeBlobClosure@@@Z+0x62
V  [jvm.dll+0x4398af]  G1MarkSweep::mark_sweep_phase1+0x9f;;  ?mark_sweep_phase1@G1MarkSweep@@CAXAA_N_N@Z+0x9f
V  [jvm.dll+0x43978c]  G1MarkSweep::invoke_at_safepoint+0x11c;;  ?invoke_at_safepoint@G1MarkSweep@@SAXPAVReferenceProcessor@@_N@Z+0x11c
V  [jvm.dll+0x422b39]  G1CollectedHeap::do_collection+0x5e9;;  ?do_collection@G1CollectedHeap@@IAE_N_N0I@Z+0x5e9
V  [jvm.dll+0x4241df]  G1CollectedHeap::do_full_collection+0xf;;  ?do_full_collection@G1CollectedHeap@@MAEX_N@Z+0xf
V  [jvm.dll+0x461d69]  VM_G1CollectFull::doit+0x29;;  ?doit@VM_G1CollectFull@@UAEXXZ+0x29
V  [jvm.dll+0x2879d3]  VM_Operation::evaluate+0x73;;  ?evaluate@VM_Operation@@QAEXXZ+0x73
V  [jvm.dll+0x285910]  VMThread::evaluate_operation+0xe0;;  ?evaluate_operation@VMThread@@AAEXPAVVM_Operation@@@Z+0xe0
V  [jvm.dll+0x2861e5]  VMThread::loop+0x3c5;;  ?loop@VMThread@@QAEXXZ+0x3c5
V  [jvm.dll+0x2867b4]  VMThread::run+0xb4;;  ?run@VMThread@@UAEXXZ+0xb4

Only full GC's are being done. If class unloading is turned off, the crash does not occur. The crash occurs with a fastdebug build but not a slowdebug build.

The crash is happening when the roots in a thread are scanned and one of the objects encountered has a class that has been unloaded. The unloading happens one or more (varies) GC's before the crash. VerifyGCBefore and VerifyGCAfter are on. Verify before and after the unloading pass. Verify before the crash passes. The crash happens on during marking for a full GC (GenMarkSweep). For example the unloading message is seen [Unloading class sun.reflect.GeneratedConstructorAccessor2 0x33b15a28] and later (later GC) the crash happens on Crashing in InstanceKlass::oop_oop_iterate_nv - obj 0x12700000 {_mark=0x00000003 {...} _metadata={_klass=0x33b15a28 {_annotations=0x00000000 <NULL> _array_klasses=...} ...} } oopDesc * + _mark 0x00000003 {...} markOopDesc * volatile + _metadata {_klass=0x33b15a28 {_annotations=0x00000000 <NULL> _array_klasses=0x00000000 <NULL> _constants=0x33b15618 {...} ...} ...} oopDesc::_metadata

I've reproduced a crash with jdk8u51 using the same testing as reported on 2015-07-16. Stack: [0x00000000187c0000,0x00000000188c0000], sp=0x00000000188be550, free sp ace=1017k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [jvm.dll+0x1c2a17] MarkSweep::follow_klass+0x17 V [jvm.dll+0x1c320f] InstanceKlass::oop_follow_contents+0x5f V [jvm.dll+0x3d92dc] MarkSweep::follow_stack+0xdc V [jvm.dll+0x3651a5] JavaThread::oops_do+0x85 V [jvm.dll+0x365f11] Threads::possibly_parallel_oops_do+0xb1 V [jvm.dll+0x183d17] SharedHeap::process_roots+0x147 V [jvm.dll+0x183f9a] SharedHeap::process_strong_roots+0x2a V [jvm.dll+0x588388] G1MarkSweep::mark_sweep_phase1+0xb8 V [jvm.dll+0x588cac] G1MarkSweep::invoke_at_safepoint+0x15c V [jvm.dll+0x575c0c] G1CollectedHeap::do_collection+0x83c V [jvm.dll+0x5a0252] VM_G1CollectFull::doit+0x92 V [jvm.dll+0x37a8e2] VM_Operation::evaluate+0x102 V [jvm.dll+0x379815] VMThread::evaluate_operation+0x155 V [jvm.dll+0x379cf6] VMThread::loop+0x366 V [jvm.dll+0x379ffb] VMThread::run+0xcb V [jvm.dll+0x3ee6ae] java_start+0xbe C [msvcr100.dll+0x21d9f] C [msvcr100.dll+0x21e3b] C [kernel32.dll+0x159dd] C [ntdll.dll+0x2a551]

I could reproduce this ACCESS_VIOLATION with b75 for '-server' mode.

I tried to reproduce with JDK9b72 fastdebug binary with Jon's option above. Same as Jon, I could get ACCESS_VIOLATION but mostly I couldn't get the stacktrace. I also tried with '-client' but I couldn't reproduce for more than 100 hours. (4days+) All options are same except replacing '-server' to '-client'. I referred Tom's comment for JDK-8130261, but the difference is that I also enabled 'TieredCompilation'. And the bug history also shows that this issue has been occurred with/without 'TieredCompilation'.

Reproduced running the test program directly with $JAVA_HOME/bin/java -Xcomp -server -XX:+PrintGCDetails -XX:+PrintHeatAtGC -XX:+S howMessageBoxOnError -XX:MaxRAMFraction=8 -XX:+CreateCoredumpOnCrash -ea -esa -X X:+TieredCompilation -XX:CompileThreshold=100 -XX:+UnlockExperimentalVMOptions - XX:+IgnoreUnrecognizedVMOptions -XX:+AggressiveOpts -XX:-UseBiasedLocking Secure DBBTest

I've reproduced an access_violation with jtreg on a 64bit windows 7 machine running the 32 bit jdk (originally jprt build jdk1.9.0.2015-07-08-193506.drlong.jdk9-comp0/fastdebug and with JDK9b72/fastdebug. I have not gotten a stacktrace from these crashes yet so don't know if it matches this bug.

These two issues *could* be related (please don't rush to conclusions). They both happen with G1MarkSweep and we are hitting the bad memory via JavaThread::oops_do. However, the stack traces are slightly different, but that could be because one crash in on Windows and the other on Solaris and the Windows debug symbols might not provide as good stacktrace as DWARF4 on Solaris...

Agree with Michail's ILW - ILW=H (Crash(ACCESS_VIOLATION)) L (affected only Windows) H(unknown) => P2