JDK-8077286 : crash in vm/gc/compact/ tests
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 9
  • Priority: P1
  • Status: Resolved
  • Resolution: Duplicate
  • Submitted: 2015-04-08
  • Updated: 2015-09-02
  • Resolved: 2015-09-02
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 :  
Testing G1 as default, two SIGSEGV in two tests (seen on MacOS)


StefanK:  Maybe humongous object reclamation, need to verify.
This crash happened at the same time as we had a number of assert failures due to JDK-8069367. The stack traces are very similar and suggests that this is the same issue, but a crash where the others hit an assert since this is a product build. The Humongous_Arrays crash is in: V [libjvm.dylib+0x1adead] oopDesc::size()+0x2d V [libjvm.dylib+0x1c8dcd] CMTask::scan_object(oopDesc*)+0x15 V [libjvm.dylib+0x1c8f0e] CMTask::drain_local_queue(bool)+0xf8 V [libjvm.dylib+0x1ca819] CMTask::do_marking_step(double, bool, bool)+0x375 V [libjvm.dylib+0x1cc9a3] CMConcurrentMarkingTask::work(unsigned int)+0xc3 V [libjvm.dylib+0x5c4195] GangWorker::loop()+0x73 V [libjvm.dylib+0x48923e] java_start(Thread*)+0xf6 The Compact_Arrays_ArrayOf crash has the same stack trace, but without symbols: V [libjvm.dylib+0x1adead] V [libjvm.dylib+0x1c8dcd] V [libjvm.dylib+0x1c8f0e] V [libjvm.dylib+0x1ca819] V [libjvm.dylib+0x1cc9a3] V [libjvm.dylib+0x5c4195] V [libjvm.dylib+0x48923e] Finally a stacktrace from one of the assert failures in JDK-8069367: V [libjvm.so+0x15f53f8] void VMError::report_and_die()+0x700;; __1cHVMErrorOreport_and_die6M_v_+0x700 V [libjvm.so+0xa7cf98] void report_vm_error(const char*,int,const char*,const char*)+0x70;; __1cPreport_vm_error6Fpkci11_v_+0x70 V [libjvm.so+0xa1a7a4] void CMTask::drain_local_queue(bool)+0x5c4;; __1cGCMTaskRdrain_local_queue6Mb_v_+0x5c4 V [libjvm.so+0xa1baa8] void CMTask::do_marking_step(double,bool,bool)+0x748;; __1cGCMTaskPdo_marking_step6Mdbb_v_+0x748 V [libjvm.so+0xa21948] void CMConcurrentMarkingTask::work(unsigned)+0x398;; __1cXCMConcurrentMarkingTaskEwork6MI_v_+0x398 V [libjvm.so+0x1659bcc] void GangWorker::loop()+0x294;; __1cKGangWorkerEloop6M_v_+0x294 V [libjvm.so+0x12abb98] java_start+0x378;; java_start+0x378 It seems as where the debug version hit an assert in drain_local_queue the product build continued a few cycles more with a bad mark bit.

ILW = High (crash), Medium (happened a few times), High (none) = P1