JDK-8075466 : SATB queue pre-filter verify found reclaimed humongous object
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 9
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2015-03-18
  • Updated: 2017-07-26
  • 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.
8u60Fixed 9 b64Fixed
Related Reports
Blocks :  
Relates :  
Relates :  
Relates :  
Assert failed:

#  Internal Error (/opt/jprt/T/P1/150515.stefank/s/hotspot/src/share/vm/oops/klass.inline.hpp:66), pid=1466, tid=1757
#  assert(check_klass_alignment(result)) failed: address not aligned: 0xffffffffcaadbabe
# JRE version: Java(TM) SE Runtime Environment (9.0) (build 1.9.0-internal-fastdebug-20150317150515.stefank.hs-gc-clean-b00)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (1.9.0-internal-fastdebug-20150317150515.stefank.hs-gc-clean-b00 mixed mode solaris-sparc compressed oops)

The address looks suspicious: 0xffffffffcaadbabe
Is this one of the magic markers, or has someone taken a cafebabe and subtracted a little?

Top of stack:

V  [libjvm.so+0x15e05a8]  void VMError::report_and_die()+0x700;;  __1cHVMErrorOreport_and_die6M_v_+0x700
V  [libjvm.so+0xa727e0]  void report_vm_error(const char*,int,const char*,const char*)+0x70;;  __1cPreport_vm_error6Fpkci11_v_+0x70
V  [libjvm.so+0x6bd4a8]  Klass*Klass::decode_klass_not_null(unsigned)+0xa8;;  __1cFKlassVdecode_klass_not_null6FI_p0_+0xa8
V  [libjvm.so+0x70c2dc]  bool oopDesc::is_oop(bool)const+0x26c;;  __1cHoopDescGis_oop6kMb_b_+0x26c
V  [libjvm.so+0x13e5f3c]  void ObjPtrQueue::verify_oops_in_buffer()+0xcc;;  __1cLObjPtrQdDueueVverify_oops_in_buffer6M_v_+0xcc
V  [libjvm.so+0x13e6180]  void SATBMarkQueueSet::handle_zero_index_for_thread(JavaThread*)+0x10;;  __1cQSATBMarkQdDueueSetbChandle_zero_index_for_thread6FpnKJavaThread__v_+0x10
v  ~RuntimeStub::g1_pre_barrier_slow Runtime1 stub
J 7063 C1 java.io.ObjectStreamClass$WeakClassKey.equals(Ljava/lang/Object;)Z (42 bytes) @ 0xffffffff6bb4cf34 [0xffffffff6bb4c7e0+0x754]
J 4960 C2 java.util.concurrent.ConcurrentHashMap.get(Ljava/lang/Object;)Ljava/lang/Object; (162 bytes) @ 0xffffffff72e03398 [0xffffffff72e03260+0x138]
J 7072 C1 java.io.ObjectStreamClass.lookup(Ljava/lang/Class;Z)Ljava/io/ObjectStreamClass; (335 bytes) @ 0xffffffff6be7c300 [0xffffffff6be7b560+0xda0]
J 7058 C1 java.io.ObjectOutputStream.writeObject0(Ljava/lang/Object;Z)V (619 bytes) @ 0xffffffff6be62b00 [0xffffffff6be616e0+0x1420]

Bugs found by nightly testing. Verified by passed nightly.

I changed the synopsis to better describe the problem.

ILW = High (crash), Low (happened once), High (unknown) = P2