JDK-8078055 : Freed heap found instead of klass
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 9
  • Priority: P2
  • Status: Resolved
  • Resolution: Duplicate
  • Submitted: 2015-04-17
  • Updated: 2015-05-05
  • Resolved: 2015-05-05
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.
Related Reports
Duplicate :  
Relates :  
Relates :  
#  Internal Error (hotspot\src\share\vm\oops/klass.inline.hpp:66), pid=117140, tid=66900
#  assert(check_klass_alignment(result)) failed: address not aligned: 0x00000000baadbabe
# JRE version: Java(TM) SE Runtime Environment (9.0) (build 1.9.0-internal-fastdebug-20150416224154.kab.hs-gc-b00)

Stack: [0xffffffff68a00000,0xffffffff68b00000],  sp=0xffffffff68afed80,  free space=1019k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x162cf64]  void VMError::report_and_die()+0x6c4;;  __1cHVMErrorOreport_and_die6M_v_+0x6c4
V  [libjvm.so+0xae00d8]  void report_vm_error(const char*,int,const char*,const char*)+0x70;;  __1cPreport_vm_error6Fpkci11_v_+0x70
V  [libjvm.so+0x6d6e08]  Klass*Klass::decode_klass_not_null(unsigned)+0xa8;;  __1cFKlassVdecode_klass_not_null6FI_p0_+0xa8
V  [libjvm.so+0x721974]  bool oopDesc::is_oop(bool)const+0x26c;;  __1cHoopDescGis_oop6kMb_b_+0x26c
V  [libjvm.so+0xa84f20]  void CMTask::deal_with_reference(oop)+0x38;;  __1cGCMTaskTdeal_with_reference6MnDoop__v_+0x38
V  [libjvm.so+0xa8291c]  void CMObjectClosure::do_object(oop)+0x4c;;  __1cPCMObjectClosureJdo_object6MnDoop__v_+0x4c
V  [libjvm.so+0x1437db4]  void ObjPtrQueue::apply_closure_to_buffer(ObjectClosure*,void**,unsigned long,unsigned long)+0x104;;  __1cLObjPtrQdDueueXapply_closure_to_buffer6FpnNObjectClosure_ppvLL_v_+0x104
V  [libjvm.so+0x1437c80]  void ObjPtrQueue::apply_closure_and_empty(ObjectClosure*)+0x20;;  __1cLObjPtrQdDueueXapply_closure_and_empty6MpnNObjectClosure__v_+0x20
V  [libjvm.so+0x157aa8c]  void Threads::threads_do(ThreadClosure*)+0x54;;  __1cHThreadsKthreads_do6FpnNThreadClosure__v_+0x54
V  [libjvm.so+0xa827e8]  void CMRemarkTask::work(unsigned)+0x1a8;;  __1cMCMRemarkTaskEwork6MI_v_+0x1a8
V  [libjvm.so+0x1693dbc]  void GangWorker::loop()+0x294;;  __1cKGangWorkerEloop6M_v_+0x294
V  [libjvm.so+0x12d3a34]  java_start+0x41c;;  java_start+0x41c

Duplicate of JDK-8079236

I think Thomas is correct and this is a variant of JDK-8075215. I'm going to leave this open rather than resolve as duplicate for now, since it's not completely identical. However, I'm pretty sure the approach to solving JDK-8075215 that I'm working on will fix this too.

ILW = High (crash), Medium (happens occasionally), Medium (turn off eager reclaim) = P2

This looks like JDK-8075215 in a different place, i.e. references in the SATB buffers are processed.