JDK-8187577 : JVM crash during gc doing concurrent marking
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 8u144
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2017-09-15
  • Updated: 2019-11-13
  • Resolved: 2018-02-07
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 10 JDK 11 JDK 8
10.0.2Fixed 11 b01Fixed 8u162Fixed
Related Reports
Duplicate :  
JDK-8202250 - Crash - ConcurrentGCThread (C 0x0000000000000006)
Duplicate :  
JDK-8202249 - Repeatingly crashing in G1 ConcurrentGCThread since 8u162
Relates :  
JDK-8234096 - Mutex rank ordering problem JVMTI LoadedClassesClosure and G1 SATB queue
Relates :  
JDK-8202250 - Crash - ConcurrentGCThread (C 0x0000000000000006)
Relates :  
JDK-8197844 - JVMTI GetLoadedClasses should use the Access API
Sub Tasks
JDK-8205376 :  
Release Note: JVM Crash during G1 GC - Closed
Description
Crash observed with G1 GC during concurrent marking with the following stack traces:
--------------------------------------------------------------------
java 8u144-b32 on Oracle linux 6 64-bit
gc: G1 is used

hs_err_pid21397.log stack trace:
Stack: [0x00007f74fc69f000,0x00007f74fc7a0000],  sp=0x00007f74fc79ea70,  free
space=1022k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native
code)
V  [libjvm.so+0x46cfaf]  ClassLoaderData::oops_do(OopClosure*, KlassClosure*,
bool)+0x8f
V  [libjvm.so+0x65b310]  InstanceMirrorKlass::oop_oop_iterate_nv(oopDesc*,
G1CMOopClosure*)+0x40
V  [libjvm.so+0x4cf034]  CMBitMapClosure::do_bit(unsigned long)+0x74
V  [libjvm.so+0x4c871e]  CMTask::do_marking_step(double, bool, bool)+0xa9e
V  [libjvm.so+0x4cf7bd]  CMConcurrentMarkingTask::work(unsigned int)+0xdd
V  [libjvm.so+0xaee2ff]  GangWorker::loop()+0xcf
V  [libjvm.so+0x92b5c8]  java_start(Thread*)+0x108

hs_err_pid23461.log
Stack: [0x00007fcc6c341000,0x00007fcc6c442000],  sp=0x00007fcc6c440a10,  free
space=1022k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native
code)
V  [libjvm.so+0x4cbd06]  oopDesc::size()+0x56
V  [libjvm.so+0x4cdc60]  CMTask::make_reference_grey(oopDesc*,
HeapRegion*)+0xc0
V  [libjvm.so+0x46cfd7]  ClassLoaderData::oops_do(OopClosure*, KlassClosure*,
bool)+0xb7
V  [libjvm.so+0x65b310]  InstanceMirrorKlass::oop_oop_iterate_nv(oopDesc*,
G1CMOopClosure*)+0x40
V  [libjvm.so+0x4cf034]  CMBitMapClosure::do_bit(unsigned long)+0x74
V  [libjvm.so+0x4c871e]  CMTask::do_marking_step(double, bool, bool)+0xa9e
V  [libjvm.so+0x4cf973]  CMConcurrentMarkingTask::work(unsigned int)+0x293
V  [libjvm.so+0xaee2ff]  GangWorker::loop()+0xcf
V  [libjvm.so+0x92b5c8]  java_start(Thread*)+0x108
Comments
Fix Request This fix was backported to JDK 8u. This should be backported to JDK 10, notably because G1 is the default collector now, and there is a high chance this bug would be exposed.
13-04-2018
I don't think we want a barrier whenever the CLDG or SD are traversed, only in the case where we load the java_mirror and store it somewhere else. I would fix this specific case for the backport to fix the customer's problem and leave examination of the other places for jdk11. Here: void do_klass(Klass* k) { // Collect all jclasses _classStack.push((jclass) _env->jni_reference(k->java_mirror())); }
09-01-2018
In this crash, Thread-2 posts a thread-start event, and in its event handler it traverses through the currently loaded classes and creates thread-local JNIHandles for the java_mirror of the loaded classes. Thread-1 initiates safepoint synchronization for the Remark phase, and thread-2 gets blocked in the event handler. Since at this point, G1 does not have the knowledge of the java_mirrors of the classes stored in Thread-2's thread-local JNIHandles, it unloads some of the otherwise unreachable classes. When these JNIHandles are later scanned, it leads to this crash. Stefan Karlsson has suggested that we add a G1 resurrection barrier for java_mirror() and class_loader() when the classes are fetched from CLDG/SD.
09-01-2018
The application failed with the following stack trace while running with VerifyDuringGC with an instrumented JVM that exits at the first verification failure: V [libjvm.so+0x4ffec2] report_vm_error(char const*, int, char const*, char const*)+0x62 V [libjvm.so+0x5b00a0] VerifyRootsClosure::do_oop(oopDesc**)+0x140 V [libjvm.so+0x7131da] JNIHandleBlock::oops_do(OopClosure*)+0x6a V [libjvm.so+0xa76891] JavaThread::oops_do(OopClosure*, CLDClosure*, CodeBlobClosure*)+0x31 V [libjvm.so+0xa77bd9] Threads::possibly_parallel_oops_do(OopClosure*, CLDClosure*, CodeBlobClosure*)+0x69 V [libjvm.so+0x5cf8ca] G1RootProcessor::process_java_roots(OopClosure*, CLDClosure*, CLDClosure*, CLDClosure*, CodeBlobClosure*, G1GCPhaseTimes*, unsigned int)+0x9a V [libjvm.so+0x5cf92d] G1RootProcessor::process_all_roots(OopClosure*, CLDClosure*, CodeBlobClosure*)+0x3d V [libjvm.so+0x5a90ba] G1CollectedHeap::verify(bool, VerifyOption)+0x1ca V [libjvm.so+0xa972fc] Universe::verify(VerifyOption, char const*, bool)+0xcc V [libjvm.so+0x4ca83d] ConcurrentMark::checkpointRootsFinal(bool)+0x43d V [libjvm.so+0xad9d3e] VM_CGC_Operation::doit()+0xae V [libjvm.so+0xad95d5] VM_Operation::evaluate()+0x55 V [libjvm.so+0xad799a] VMThread::evaluate_operation(VM_Operation*)+0xba V [libjvm.so+0xad7d1e] VMThread::loop()+0x1ce V [libjvm.so+0xad8190] VMThread::run()+0x70 V [libjvm.so+0x92e408] java_start(Thread*)+0x108 VMThread failed while looking at the thread-local JNIHandles of the following thread: #6 0x00007f8af1709657 in SafepointSynchronize::block (thread=0x7f8a24147000) #7 0x00007f8af17be85d in JavaThread::check_safepoint_and_suspend_for_native_trans (thread=0x7f8a24147000) #8 0x00007f8af142f3cd in transition_from_native (env=<value optimized out>, r1=0x7f8a882e0228, r2=0x7f8a344dec78) #9 trans_from_native (env=<value optimized out>, r1=0x7f8a882e0228, r2=0x7f8a344dec78) #10 ThreadInVMfromNative (env=<value optimized out>, r1=0x7f8a882e0228, r2=0x7f8a344dec78) #11 jni_IsSameObject (env=<value optimized out>, r1=0x7f8a882e0228, r2=0x7f8a344dec78) #12 0x00007f8af01c12ce in classTrack_processUnloads () #13 0x00007f8af01c9533 in event_callback () #14 0x00007f8af01ca364 in cbThreadStart () #15 0x00007f8af14e206f in JvmtiExport::post_thread_start (thread=0x7f8a24147000) #16 0x00007f8af17c3485 in JavaThread::run (this=0x7f8a24147000) #17 0x00007f8af1672408 in java_start (thread=0x7f8a24147000) #18 0x00007f8af2533e25 in start_thread () #19 0x00007f8af1e3c34d in clone () GC logs show: 2017-12-19T18:44:58.385-0500: 7387.284: [Finalize Marking, 0.0029249 secs] 2017-12-19T18:44:58.388-0500: 7387.287: [GC ref-proc, 0.0777165 secs] 2017-12-19T18:44:58.466-0500: 7387.364: [Unloading, 0.3807630 secs] VerifyDuringGC:(after)[Verifying Threads Heap Roots Root location 0x00007f8a783e8228 points to dead obj 0x00000006d4c00a00 java.lang.Class - klass: 'java/lang/Class'
08-01-2018