JDK-6415354 : CMS: assert(thisOop->is_oop_or_null(true),"expected an oop or NULL")
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 5.0u6,6
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS:
    linux_2.6,solaris_9,solaris_nevada,windows_xp linux_2.6,solaris_9,solaris_nevada,windows_xp
  • CPU: x86,sparc
  • Submitted: 2006-04-19
  • Updated: 2010-12-03
  • Resolved: 2006-08-16
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 JDK 6
5.0u19Fixed 6 b96Fixed
Related Reports
Duplicate :  
JDK-6431128 - mustang crash in vtable chunks with netbeans and cms
Relates :  
JDK-6588423 - JVM crash in client compiler
Relates :  
JDK-6490031 - CMS: assert(size > 0,"no unparsable object found"), concurrentMarkSweepGeneration.cpp, 6528
Description
http://vmsqe.sfbay/nightly/mantis/DTWS/results/04-18-06/ClientVM/Solsparc/mixed/Gc_Baseline-Xconc/RT_PLUMHALL-19-NIGHTLY-Gc_Baseline-Xconc-ClientVM-mixed-Solsparc-2006-04-19-04-13-05/hs_err_pid25365.log

shows an assertion failure

    # Error: assert(thisOop->is_oop_or_null(true),"expected an oop or NULL")

with this stack trace:

    Stack: [0xfae00000,0xfae80000),  sp=0xfae7f4b8,  free space=509k
    Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
    V  [libjvm.so+0xcfc084];;  void VMError::report_and_die()+0x7f8
    V  [libjvm.so+0x3b2f70];;  void report_assertion_failure(const char*,int,const char*)+0x70
    V  [libjvm.so+0x37c5e0];;  void PushOrMarkClosure::do_oop(oop*)+0x84
    V  [libjvm.so+0x393490];;  int constantPoolKlass::oop_oop_iterate(oop,OopClosure*)+0x2a0
    V  [libjvm.so+0x76e7c];;  int Klass::oop_oop_iterate_v(oop,OopClosure*)+0x60
    V  [libjvm.so+0x3799f8];;  void MarkFromRootsClosure::scanOopsInOop(HeapWord*)+0xb78
    V  [libjvm.so+0x378c80];;  void MarkFromRootsClosure::do_bit(unsigned)+0x614
    V  [libjvm.so+0xe7f9c];;  void BitMap::iterate(BitMapClosure*,unsigned,unsigned)+0xec
    V  [libjvm.so+0x365488];;  bool CMSCollector::do_marking_st(bool)+0x24c
    V  [libjvm.so+0x3611f4];;  bool CMSCollector::markFromRoots(bool)+0x1c4
    V  [libjvm.so+0x35b278];;  void CMSCollector::collect_in_background(bool)+0xcc0
    V  [libjvm.so+0x388d3c];;  void ConcurrentMarkSweepThread::run()+0x814
    V  [libjvm.so+0xa870e0];;  java_start+0x17c
Comments
SUGGESTED FIX /net/prt-archiver/data/archived_workspaces/main/gc_baseline/2006/20060806201917.jmasa.gc_baseline_6415354
07-08-2007
SUGGESTED FIX A second change was made for this bug to better detect unparsable objects. *** 6465,6479 **** // Note that pre-cleaning needn't redirty the card. OopDesc::set_klass() // will dirty the card when the klass pointer is installed in the // object (signalling the completion of initialization). } } else { ! // an unmarked object; ignore mark word in verification below ! // since we are running concurrent with mutators assert(p->is_oop(true), "should be an oop"); size = CompactibleFreeListSpace::adjustObjectSize(p->size()); } assert(_markStack->isEmpty(), "post-condition (eager drainage)"); assert(size > 0, "no unparsable object found"); return size; } --- 6466,6486 ---- // Note that pre-cleaning needn't redirty the card. OopDesc::set_klass() // will dirty the card when the klass pointer is installed in the // object (signalling the completion of initialization). } } else { ! ! // Either a not yet marked object or an uninitialized object: ! // we merely need to compute its size so as to go look at the next ! // block. ! if (p->klass() == NULL || !p->is_parsable()) { ! size = 0; // An uninitialized object ! } else { // an object not (yet) reached by marking assert(p->is_oop(true), "should be an oop"); size = CompactibleFreeListSpace::adjustObjectSize(p->size()); } + } assert(_markStack->isEmpty(), "post-condition (eager drainage)"); assert(size > 0, "no unparsable object found"); return size; }
21-12-2006
SUGGESTED FIX The slots that changes from integer to references are tagged to identify the current contents. The slots only go from integer to reference. Currently the tag is changed from an integer tag to a reference tag and then a reference is put into the slot. Put a 0 in the slot before changing the tag. A 0 will appear as a NULL reference if the CMS precleaning finds the slot and will be ignored. When the reference is written into the slot, the card covering the slot will be dirtied so the slot will be revisited.
02-08-2006
EVALUATION During class file parsing there are slots that change from an integer (constant pool index) to a reference. These transitions are done by the time the class has been created so are normally not seen by other parts of the VM. A class can be seen in transition by CMS during precleaning if it is covered by a dirty card.
02-08-2006