JDK-8077284 : assert((*t)->is_oop_or_null()) failed: Expected an oop or NULL
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 9
  • Priority: P1
  • Status: Resolved
  • Resolution: Duplicate
  • Submitted: 2015-04-08
  • Updated: 2015-04-16
  • Resolved: 2015-04-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.
JDK 9
9Resolved
Related Reports
Blocks :  
Duplicate :  
Description
Testing G1 as default.

# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/opt/jprt/T/P1/075059.sjohanss/s/hotspot/src/share/vm/utilities/taskqueue.hpp:334), pid=3078, tid=2742713232
#  assert((*t)->is_oop_or_null()) failed: Expected an oop or NULL at 0xa9200000
#
# JRE version: Java(TM) SE Runtime Environment (9.0) (build 1.9.0-internal-fastdebug-20150330075059.sjohanss.g1-server-defaul-b00)
# Java VM: Java HotSpot(TM) Server VM (1.9.0-internal-fastdebug-20150330075059.sjohanss.g1-server-defaul-b00 compiled mode linux-x86 )
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
#

---------------  T H R E A D  ---------------

Current thread (0xa363dc00):  VMThread [stack: 0xa3727000,0xa37a8000] [id=3099]

Stack: [0xa3727000,0xa37a8000],  sp=0xa37a6ad0,  free space=510k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x104cc98]  VMError::report_and_die()+0x198
V  [libjvm.so+0x6d8df6]  report_vm_error(char const*, int, char const*, char const*)+0x76
V  [libjvm.so+0x680714]  ConcurrentMark::verify_no_cset_oops(bool, bool, bool, bool)+0x844
V  [libjvm.so+0x7f0bf5]  G1CollectedHeap::do_collection_pause_at_safepoint(double)+0xc65
V  [libjvm.so+0x107c540]  VM_G1IncCollectionPause::doit()+0xc0
V  [libjvm.so+0x107a727]  VM_Operation::evaluate()+0x97
V  [libjvm.so+0x1077c35]  VMThread::evaluate_operation(VM_Operation*)+0x145
V  [libjvm.so+0x1078585]  VMThread::loop()+0x4e5
V  [libjvm.so+0x10787cc]  VMThread::run()+0xcc
V  [libjvm.so+0xd90af0]  java_start(Thread*)+0x100
C  [libpthread.so.0+0x5832]

VM_Operation (0xa285c878): G1IncCollectionPause, mode: safepoint, requested by thread 0xa290cc00
Comments
This is another variation of JDK-8069367, where we have a humongous object in a per-thread mark queue when the humongous object is reclaimed. The candidate fix for JDK-8069367 that is in review should fix this too.
10-04-2015

ILW = High (crash), Medium (happened a few times), High (none) = P1
10-04-2015