JDK-6997298 : fatal error: must own lock CMS_markBitMap_lock during heap dump
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: hs20
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2010-11-03
  • Updated: 2011-03-07
  • Resolved: 2011-03-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 6 JDK 7 Other
6u25Fixed 7Fixed hs20Fixed
Related Reports
Relates :  
JDK-7000578 - CMS: assert(SafepointSynchronize::is_at_safepoint()) failed: Else races are possible
Relates :  
JDK-6689653 - JMapPerm fails with UseConcMarkSweepIncGC and compressed oops off
Description
Heapdump test fails with

#  Internal Error (C:\temp\jprt\P1\B\214116.iv159533\source\src\share\vm\runtime\mutexLocker.cpp:144), pid=14872, tid=23676
#  fatal error: must own lock CMS_markBitMap_lock

V  [jvm.dll+0x38373c];;  ?report_and_die@VMError@@QAEXXZ+0x4ec
V  [jvm.dll+0x1268f6];;  ?report_fatal@@YAXPBDH0@Z+0x46
V  [jvm.dll+0x2b8367];;  ?assert_lock_strong@@YAXPBVMonitor@@@Z+0x67
V  [jvm.dll+0xdf5ba];;  ?assert_locked@CMSLockVerifier@@SAXPBVMutex@@00@Z+0x1da
V  [jvm.dll+0x108f7d];;  ?assert_locked@CMSBitMap@@QBEXXZ+0xd
V  [jvm.dll+0xec4f9];;  ?obj_is_alive@CompactibleFreeListSpace@@UBE_NPBVHeapWord@@@Z+0x49
V  [jvm.dll+0xe9e0e];;  ?safe_object_iterate@CompactibleFreeListSpace@@UAEXPAVObjectClosure@@@Z+0x8e
V  [jvm.dll+0x16a491];;  ?do_space@GenerationSafeObjIterateClosure@@UAEXPAVSpace@@@Z+0x11
V  [jvm.dll+0x106194];;  ?space_iterate@ConcurrentMarkSweepGeneration@@UAEXPAVSpaceClosure@@_N@Z+0x14
V  [jvm.dll+0x16a4be];;  ?safe_object_iterate@Generation@@UAEXPAVObjectClosure@@@Z+0x1e
V  [jvm.dll+0x1081ec];;  ?safe_object_iterate@ConcurrentMarkSweepGeneration@@UAEXPAVObjectClosure@@@Z+0x4c
V  [jvm.dll+0x161252];;  ?safe_object_iterate@GenCollectedHeap@@UAEXPAVObjectClosure@@@Z+0x22
V  [jvm.dll+0x1725f5];;  ?doit@VM_HeapDumper@@UAEXXZ+0x2d5
V  [jvm.dll+0x387d34];;  ?evaluate@VM_Operation@@QAEXXZ+0x74
V  [jvm.dll+0x386b2c];;  ?evaluate_operation@VMThread@@AAEXPAVVM_Operation@@@Z+0x8c
V  [jvm.dll+0x386f38];;  ?loop@VMThread@@QAEXXZ+0x358
V  [jvm.dll+0x3876b1];;  ?run@VMThread@@UAEXXZ+0xb1
V  [jvm.dll+0x2d0674];;  ?java_start@@YGIPAVThread@@@Z+0xb4
C  [msvcr71.dll+0x9565]
C  [kernel32.dll+0x13677]
C  [ntdll.dll+0x39d42]
C  [ntdll.dll+0x39d15]
Comments
EVALUATION http://hg.openjdk.java.net/jdk7/build/hotspot/rev/899bbbdcb6ea
25-12-2010
SUGGESTED FIX http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/899bbbdcb6ea
08-11-2010
EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/899bbbdcb6ea
08-11-2010
SUGGESTED FIX diff -r c766bae6c14d src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp --- a/src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp Thu Oct 28 14:46:29 2010 -0700 +++ b/src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp Thu Nov 04 16:23:20 2010 -0700 @@ -1093,7 +1093,8 @@ bool CompactibleFreeListSpace::block_is_ // perm_gen_verify_bit_map where we store the "deadness" information if // we did not sweep the perm gen in the most recent previous GC cycle. bool CompactibleFreeListSpace::obj_is_alive(const HeapWord* p) const { - assert (block_is_obj(p), "The address should point to an object"); + assert(block_is_obj(p), "The address should point to an object"); + assert(SafepointSynchronize::is_at_safepoint(), "Else races are possible"); // If we're sweeping, we use object liveness information from the main bit map // for both perm gen and old gen. @@ -1102,9 +1103,14 @@ bool CompactibleFreeListSpace::obj_is_al // main marking bit map (live_map below) is locked, // OR we're in other phases and perm_gen_verify_bit_map (dead_map below) // is stable, because it's mutated only in the sweeping phase. + // NOTE: This method is also used by jmap where, if class unloading is + // off, the results can return "false" for legitimate perm objects, + // when we are not in the midst of a sweeping phase, which can result + // in jmap not reporting certain perm gen objects. This will be moot + // if/when the perm gen goes away in the future. if (_collector->abstract_state() == CMSCollector::Sweeping) { CMSBitMap* live_map = _collector->markBitMap(); - return live_map->isMarked((HeapWord*) p); + return live_map->par_isMarked((HeapWord*) p); } else { // If we're not currently sweeping and we haven't swept the perm gen in // the previous concurrent cycle then we may have dead but unswept objects
04-11-2010
EVALUATION Locking anomaly.
03-11-2010