JDK-7009266 : G1: assert(obj->is_oop_or_null(true )) failed: Error
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: hs20,hs21
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2010-12-28
  • Updated: 2013-09-18
  • Resolved: 2011-05-10
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 7 Other
7Fixed hs21Fixed
Related Reports
Duplicate :  
Duplicate :  
Duplicate :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Description
Application crashes with

# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/tmp/workspace/jdk7-2-build-solaris-i586-product/jdk7/hotspot/src/share/vm/gc_implementation/g1/concurrentMark.cpp:3068), pid=11075, tid=13
#  assert(obj->is_oop_or_null(true )) failed: Error
#
# JRE version: 7.0-b123
# Java VM: Java HotSpot(TM) Client VM (20.0-b04-fastdebug compiled mode solaris-x86 )

Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x15fa03a]  void VMError::report(outputStream*)+0x73e;;  void VMError::report(outputStream*)+0x73e
V  [libjvm.so+0x15fb1e1]  void VMError::report_and_die()+0x555;;  void VMError::report_and_die()+0x555
V  [libjvm.so+0x7bd45e]  void report_vm_error(const char*,int,const char*,const char*)+0x53a;;  void report_vm_error(const char*,int,const char*,const char*)+0x53a
V  [libjvm.so+0x15fab76]  void VMError::report(outputStream*)+0x127a;;  void VMError::report(outputStream*)+0x127a
V  [libjvm.so+0x15fb1e1]  void VMError::report_and_die()+0x555;;  void VMError::report_and_die()+0x555
V  [libjvm.so+0x7bd45e]  void report_vm_error(const char*,int,const char*,const char*)+0x53a;;  void report_vm_error(const char*,int,const char*,const char*)+0x53a
V  [libjvm.so+0x6f2b61]  void CMOopClosure::do_oop(oop*)+0x975;;  void CMOopClosure::do_oop(oop*)+0x975
V  [libjvm.so+0x9a9539]  int instanceKlass::oop_oop_iterate_v(oop,OopClosure*)+0x221;;  int instanceKlass::oop_oop_iterate_v(oop,OopClosure*)+0x221
V  [libjvm.so+0x6f3aaa]  bool CMBitMapClosure::do_bit(unsigned)+0x54e;;  bool CMBitMapClosure::do_bit(unsigned)+0x54e
V  [libjvm.so+0x2deaa4]  bool BitMap::iterate(BitMapClosure*,unsigned,unsigned)+0xa4;;  bool BitMap::iterate(BitMapClosure*,unsigned,unsigned)+0xa4
V  [libjvm.so+0x6df120]  bool CMBitMapRO::iterate(BitMapClosure*,MemRegion)+0x5c;;  bool CMBitMapRO::iterate(BitMapClosure*,MemRegion)+0x5c
V  [libjvm.so+0x6ed8f8]  void CMTask::do_marking_step(double)+0x354;;  void CMTask::do_marking_step(double)+0x354
V  [libjvm.so+0x6f0a9c]  void CMConcurrentMarkingTask::work(int)+0x2d8;;  void CMConcurrentMarkingTask::work(int)+0x2d8
V  [libjvm.so+0x164d420]  void GangWorker::loop()+0x49c;;  void GangWorker::loop()+0x49c
V  [libjvm.so+0x164ce14]  void GangWorker::run()+0x24;;  void GangWorker::run()+0x24
V  [libjvm.so+0x128d7ff]  java_start+0x6fb;;  java_start+0x6fb
C  [libc.so.1+0xa71d0]  _thr_setup+0x4e;;  _thr_setup+0x4e
C  [libc.so.1+0xa74c0]  __moddi3+0x60;;  _lwp_start+0x0

Comments
EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/e1162778c1c8
23-04-2011

EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/e1162778c1c8
07-04-2011

EVALUATION References do not conform to SATB behavior - an object may be only weakly reachable at the start of marking but can then become strongly reachable (by storing a referent object into the field of another strongly reachable object) before the end of marking. The SATB pre barrier does record the targets of such writes - only the previous values.
02-02-2011

SUGGESTED FIX Possible fixes: 1. Modify the Java code of java/lang/ref/Reference.get to force the enqueing of a referent object in an SATB update buffer. 2. Intrinsify Reference.get in C1, C2 and the interpreter to do the same thing. 3. Make Reference.get a native routine; implement in the JVM and add code register the referent with the G1 pre-write barrier.
02-02-2011