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.
JDK 9
9Resolved
Related Reports
Relates :  
JDK-8130261 - G1 SEGV in MarkSweep::mark_and_push()
Relates :  
JDK-8071507 - (ref) Clear phantom reference as soft and weak references do
Description
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
Comments
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.
02-10-2015
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
02-10-2015
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]
18-08-2015
I could reproduce this ACCESS_VIOLATION with b75 for '-server' mode.
13-08-2015
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'.
13-08-2015
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
30-07-2015
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.
16-07-2015
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...
10-07-2015
Agree with Michail's ILW - ILW=H (Crash(ACCESS_VIOLATION)) L (affected only Windows) H(unknown) => P2
06-07-2015