-
Bug
-
Resolution: Fixed
-
P2
-
9
-
b64
-
Verified
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8082673 | emb-9 | Kim Barrett | P2 | Resolved | Fixed | team |
JDK-8086524 | 8u65 | Kim Barrett | P2 | Resolved | Fixed | b01 |
JDK-8078852 | 8u60 | Kim Barrett | P2 | Closed | Fixed | b17 |
JDK-8137598 | emb-8u65 | Unassigned | P2 | Resolved | Fixed | b01 |
JDK-8086140 | emb-8u60 | Kim Barrett | P2 | Resolved | Fixed | team |
# 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]
- backported by
-
JDK-8082673 SATB queue pre-filter verify found reclaimed humongous object
-
- Resolved
-
-
JDK-8086140 SATB queue pre-filter verify found reclaimed humongous object
-
- Resolved
-
-
JDK-8086524 SATB queue pre-filter verify found reclaimed humongous object
-
- Resolved
-
-
JDK-8137598 SATB queue pre-filter verify found reclaimed humongous object
-
- Resolved
-
-
JDK-8078852 SATB queue pre-filter verify found reclaimed humongous object
-
- Closed
-
- blocks
-
JDK-8077571 ObjPtrQueue is poorly named
-
- Resolved
-
- relates to
-
JDK-8078055 Freed heap found instead of klass
-
- Closed
-
-
JDK-8078023 verify_no_cset_oops found reclaimed humongous object in SATB buffer
-
- Resolved
-
-
JDK-8075215 SATB buffer processing found reclaimed humongous object
-
- Closed
-