JDK-8129961 : SIGSEGV when copying to survivor space
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 9
  • Priority: P1
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2015-06-26
  • Updated: 2023-08-21
  • Resolved: 2015-07-13
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
9 b75Fixed
Related Reports
Duplicate :  
JDK-8130684 - share/vm/memory/iterator.inline.hpp:63 assert(Universe::heap()->is_in_closed_subset(o)) failed: should be in closed
Duplicate :  
JDK-8130251 - SIGSEGV: Problematic frame: C1 ExecutorCompletionServiceLoops.oneTest(I)V (146 bytes)
Duplicate :  
JDK-8130295 - segv in size_given_klass() called from copy_to_survivor_space()
Duplicate :  
JDK-8130342 - ClassCastException in javac while compiling tests
Duplicate :  
JDK-8129592 - MarkResetTest.sh SEGV
Duplicate :  
JDK-8130070 - closed/com/oracle/jfr/gc/GarbageCollectionEventTest/TestYoungGarbageCollectionEventWithDefNew.java and closed/com/oracle/jfr/gc/ReferenceStatisticsEventTest/TestReferenceStatisticsEventWithDefNew.java crash on 32bits
Relates :  
JDK-8130295 - segv in size_given_klass() called from copy_to_survivor_space()
Relates :  
JDK-8130070 - closed/com/oracle/jfr/gc/GarbageCollectionEventTest/TestYoungGarbageCollectionEventWithDefNew.java and closed/com/oracle/jfr/gc/ReferenceStatisticsEventTest/TestReferenceStatisticsEventWithDefNew.java crash on 32bits
Description
#  SIGSEGV (0xb) at pc=0xf68e10ec, pid=21953, tid=0xe3cd3b70
#
# JRE version: Java(TM) SE Runtime Environment (9.0) (build 1.9.0-internal-fastdebug-20150625170323.jdenise.hs-rt-final-b00)
# Java VM: Java HotSpot(TM) Client VM (1.9.0-internal-fastdebug-20150625170323.jdenise.hs-rt-final-b00 mixed mode linux-x86 )
# Problematic frame:
# V  [libjvm.so+0x3690ec]  oopDesc::size_given_klass(Klass*)+0xc


V  [libjvm.so+0x3690ec]  oopDesc::size_given_klass(Klass*)+0xc;;  oopDesc::size_given_klass(Klass*)+0xc
V  [libjvm.so+0x3f4d00]  DefNewGeneration::copy_to_survivor_space(oop)+0x60;;  DefNewGeneration::copy_to_survivor_space(oop)+0x60
V  [libjvm.so+0x4ff1cb]  void FastScanClosure::do_oop_work<oop>(oop*)+0xab;;  void FastScanClosure::do_oop_work<oop>(oop*)+0xab
V  [libjvm.so+0x4ff4f2]  int InstanceKlass::oop_oop_iterate<true, FastScanClosure>(oop, FastScanClosure*)+0x102;;  int InstanceKlass::oop_oop_iterate<true, FastScanClosure>(oop, FastScanClosure*)+0x102
V  [libjvm.so+0x4f8fb1]  InstanceKlass::oop_oop_iterate_nv(oop, FastScanClosure*)+0x31;;  InstanceKlass::oop_oop_iterate_nv(oop, FastScanClosure*)+0x31
V  [libjvm.so+0x99f82a]  ContiguousSpace::oop_since_save_marks_iterate_nv(FastScanClosure*)+0x6a;;  ContiguousSpace::oop_since_save_marks_iterate_nv(FastScanClosure*)+0x6a
V  [libjvm.so+0x3f0ef2]  DefNewGeneration::oop_since_save_marks_iterate_nv(FastScanClosure*)+0x42;;  DefNewGeneration::oop_since_save_marks_iterate_nv(FastScanClosure*)+0x42
V  [libjvm.so+0x4f22ca]  GenCollectedHeap::oop_since_save_marks_iterate(GenCollectedHeap::GenerationType, FastScanClosure*, FastScanClosure*)+0x4a;;  GenCollectedHeap::oop_since_save_marks_iterate(GenCollectedHeap::GenerationType, FastScanClosure*, FastScanClosure*)+0x4a
V  [libjvm.so+0x3f3972]  DefNewGeneration::collect(bool, bool, unsigned int, bool)+0x662;;  DefNewGeneration::collect(bool, bool, unsigned int, bool)+0x662
V  [libjvm.so+0x4f175b]  GenCollectedHeap::collect_generation(Generation*, bool, unsigned int, bool, bool, bool, bool)+0x22b;;  GenCollectedHeap::collect_generation(Generation*, bool, unsigned int, bool, bool, bool, bool)+0x22b
V  [libjvm.so+0x4f3caf]  GenCollectedHeap::do_collection(bool, bool, unsigned int, bool, GenCollectedHeap::GenerationType)+0x66f;;  GenCollectedHeap::do_collection(bool, bool, unsigned int, bool, GenCollectedHeap::GenerationType)+0x66f
V  [libjvm.so+0x34f6d1]  GenCollectorPolicy::satisfy_failed_allocation(unsigned int, bool)+0xe1;;  GenCollectorPolicy::satisfy_failed_allocation(unsigned int, bool)+0xe1
V  [libjvm.so+0xa97b5c]  VM_GenCollectForAllocation::doit()+0xbc;;  VM_GenCollectForAllocation::doit()+0xbc
V  [libjvm.so+0xac1357]  VM_Operation::evaluate()+0x97;;  VM_Operation::evaluate()+0x97
V  [libjvm.so+0xabe775]  VMThread::evaluate_operation(VM_Operation*)+0x145;;  VMThread::evaluate_operation(VM_Operation*)+0x145
V  [libjvm.so+0xabf0c5]  VMThread::loop()+0x4e5;;  VMThread::loop()+0x4e5
V  [libjvm.so+0xabf30c]  VMThread::run()+0xcc;;  VMThread::run()+0xcc
V  [libjvm.so+0x8a0f20]  java_start(Thread*)+0xe0;;  java_start(Thread*)+0xe0
Comments
Bugs found by nightly testing. Verified by passed nightly.
26-07-2017
URL: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/726a9b9243e0 User: lana Date: 2015-07-29 20:40:04 +0000
29-07-2015
URL: http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/726a9b9243e0 User: jmasa Date: 2015-07-13 20:04:58 +0000
13-07-2015
Since the bug is already in Main_Baseline, I removed the 'integration_blocker' tag.
09-07-2015
What's the current status for this issue?
06-07-2015
JDK-8130295 "segv in size_given_klass() called from copy_to_survivor_space()" was linked to this bug today. The failure mode in JDK-8130295 is Serial GC and Client VM in a JigSaw repo. Does anyone know if the JigSaw repo picked up changes from RT_Baseline or ... Update: JDK-8130295 talks about jigsaw, but the JPRT job that was used for this testing is: 2015-06-25-170323.jdenise.hs-rt-final which was a push to RT_Baseline for the jimage refresh bits. JDK-8130295 should likely be closed as a duplicate of this bug (JDK-8129961).
03-07-2015
OK I'm confused about the "integration_blocker" status for this bug. The following bug was closed as a duplicate of this bug: JDK-8029448 SIGSEGV in ConcurrentGCThread, Problematic frame: oopDesc::size_given_klass(Klass*)+0xc JDK-8029448 was filed on 2013.12.03 and the last comment was added on 2014.09.09. If this failure mode is really that old, then this bug (JDK-8129961) is not really an integration_blocker. Based on this history for this bug, it looks like Jesper filed it with the integration_blocker tag set. Jesper, do you concur that this bug has been around a long time and does not meet the integration_blocker criteria?
02-07-2015
ILW = High (crash), High (frequent), High (none) = P1
29-06-2015