JDK-8030832 : Crash at ClassLoaderData::claim when performing CMSParMarkTask::do_young_space_rescan while running test nsk/stress/except/except012
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: hs25,8
  • Priority: P2
  • Status: Closed
  • Resolution: Duplicate
  • Submitted: 2013-12-19
  • Updated: 2013-12-27
  • Resolved: 2013-12-27
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.
Other
hs25Resolved
Related Reports
Duplicate :  
JDK-8028497 - SIGSEGV at ClassLoaderData::oops_do(OopClosure*, KlassClosure*, bool)
Description
Test: nsk/stress/except/except012
Stack: [0x14f10000,0x14f60000],  sp=0x14f5eee0,  free space=315k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [jvm.dll+0x35466]  ClassLoaderData::claim+0x6;;  ?claim@ClassLoaderData@@AAE_NXZ+0x6
V  [jvm.dll+0x354d1]  ClassLoaderData::oops_do+0x11;;  ?oops_do@ClassLoaderData@@QAEXPAVOopClosure@@PAVKlassClosure@@_N@Z+0x11
V  [jvm.dll+0x21c245]  CMSOopsInGenClosure::do_class_loader_data+0x15;;  ?do_class_loader_data@CMSOopsInGenClosure@@UAEXPAVClassLoaderData@@@Z+0x15
V  [jvm.dll+0x21f281]  CMSOopsInGenClosure::do_klass+0x11;;  ?do_klass@CMSOopsInGenClosure@@UAEXPAVKlass@@@Z+0x11
V  [jvm.dll+0xb33db]  InstanceMirrorKlass::oop_oop_iterate_v+0x3b;;  ?oop_oop_iterate_v@InstanceMirrorKlass@@UAEHPAVoopDesc@@PAVExtendedOopClosure@@@Z+0x3b
V  [jvm.dll+0x9785f]  ContiguousSpace::par_oop_iterate+0x2f;;  ?par_oop_iterate@ContiguousSpace@@QAEXVMemRegion@@PAVExtendedOopClosure@@@Z+0x2f
V  [jvm.dll+0x220988]  CMSParMarkTask::do_young_space_rescan+0xb8;;  ?do_young_space_rescan@CMSParMarkTask@@IAEXIPAVOopsInGenClosure@@PAVContiguousSpace@@PAPAVHeapWord@@I@Z+0xb8
V  [jvm.dll+0x222f41]  CMSParMarkTask::work_on_young_gen_roots+0x81;;  ?work_on_young_gen_roots@CMSParMarkTask@@IAEXIPAVOopsInGenClosure@@@Z+0x81
V  [jvm.dll+0x224733]  CMSParInitialMarkTask::work+0xd3;;  ?work@CMSParInitialMarkTask@@UAEXI@Z+0xd3
V  [jvm.dll+0x2261fa]  CMSCollector::checkpointRootsInitialWork+0x18a;;  ?checkpointRootsInitialWork@CMSCollector@@AAEX_N@Z+0x18a
V  [jvm.dll+0x227672]  CMSCollector::checkpointRootsInitial+0xb2;;  ?checkpointRootsInitial@CMSCollector@@QAEX_N@Z+0xb2
V  [jvm.dll+0x2290e1]  CMSCollector::do_CMS_operation+0x171;;  ?do_CMS_operation@CMSCollector@@IAEXW4CMS_op_type@1@W4Cause@GCCause@@@Z+0x171
V  [jvm.dll+0x22ad6b]  VM_CMS_Initial_Mark::doit+0x5b;;  ?doit@VM_CMS_Initial_Mark@@UAEXXZ+0x5b
V  [jvm.dll+0x169d9b]  VM_Operation::evaluate+0x3b;;  ?evaluate@VM_Operation@@QAEXXZ+0x3b
V  [jvm.dll+0x169171]  VMThread::evaluate_operation+0xa1;;  ?evaluate_operation@VMThread@@AAEXPAVVM_Operation@@@Z+0xa1
V  [jvm.dll+0x169587]  VMThread::loop+0x2f7;;  ?loop@VMThread@@QAEXXZ+0x2f7
V  [jvm.dll+0x169782]  VMThread::run+0x62;;  ?run@VMThread@@UAEXXZ+0x62
V  [jvm.dll+0x1a8fe6]  java_start+0x86;;  ?java_start@@YGIPAVThread@@@Z+0x86
C  [msvcr100.dll+0x5c556]
C  [msvcr100.dll+0x5c600]
C  [kernel32.dll+0x13677]
C  [ntdll.dll+0x39f42]
C  [ntdll.dll+0x39f15]

VM_Operation (0x0113f7d0): CMS_Initial_Mark, mode: safepoint, requested by thread 0x0100ec00

OS: Windows Server 2008 R2 , 64 bit Build 7600 

jvm_args: -Xmixed -XX:+UseConcMarkSweepGC 
java_command: nsk.stress.except.except012.except012
java_class_path (initial): C:/local/aurora/sandbox/results/ResultDir/except012;C:/local/aurora/sandbox/sca/vmsqe/testbase/vm/8/build/execution/vm//bin/classes;C:/local/aurora/sandbox/java/re/jdk/8/promoted/all/b120/binaries/windows-i586//lib/tools.jar
Comments
I have investigated the mdmp crash file and the situation is indeed very similar to JDK-8028497, CMS is running an initial mark just after a class has been logged as "loaded" in the hs_err messages section. When initial mark encounters the mirror (java/lang/Class object) for that class it points to an InstanceKlass object which is not in a proper state. The InstanceKlass' contents has been cleared out by the "remove_unsharable_info" operation from CDS, its _class_loader_data and _java_mirror fields are NULL, its _init_state is 1, etc.
27-12-2013
ILW => HLH => P2 Impact: High, VM is crahsing Likelihood: Low, haven't been able to reproduced locally and not seen a lot in testing. Workaround: High, no known workaround. Needs some more investigation to verify if this is a dup of JDK-8028497. Have tried to reproduce the issue to see if it went away when turning of CDS, but so far no luck in reproducing.
23-12-2013
CMS+Class data sharing + crashing when trying to walk a CLD, this may be a duplicate of JDK-8028497
20-12-2013
RULE nsk/stress/except/except012 Crash EXCEPTION_ACCESS_VIOLATION
20-12-2013