JDK-8068453 : SIGSEGV in PSOldGen SpaceMangler
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 9
  • Priority: P2
  • Status: Closed
  • Resolution: Cannot Reproduce
  • Submitted: 2015-01-05
  • Updated: 2015-01-26
  • Resolved: 2015-01-26
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
9Resolved
Related Reports
Relates :  
JDK-8068478 - SIGSEGV in CMS TestVirtualSpace::test()
Description
Stack:
C  [libc.so.1+0x5bff8]  strlen+0x18;;  strlen+0x18
V  [libjvm.so+0xa72820]  void report_vm_error(const char*,int,const char*,const char*)+0x38;;  __1cPreport_vm_error6Fpkci11_v_+0x38
V  [libjvm.so+0x143600c]  void SpaceMangler::check_mangled_unused_area(HeapWord*)+0x1bc;;  __1cMSpaceManglerZcheck_mangled_unused_area6MpnIHeapWord__v_+0x1bc
V  [libjvm.so+0x1352898]  bool PSOldGen::expand_by(unsigned long)+0x108;;  __1cIPSOldGenJexpand_by6ML_b_+0x108
V  [libjvm.so+0x1352680]  void PSOldGen::expand(unsigned long)+0x100;;  __1cIPSOldGenGexpand6ML_v_+0x100
V  [libjvm.so+0x1352d44]  void PSOldGen::resize(unsigned long)+0x1b4;;  __1cIPSOldGenGresize6ML_v_+0x1b4
V  [libjvm.so+0x1361fc0]  bool PSParallelCompact::invoke_no_policy(bool)+0x988;;  __1cRPSParallelCompactQinvoke_no_policy6Fb_b_+0x988
V  [libjvm.so+0x13752ac]  bool PSScavenge::invoke()+0x31c;;  __1cKPSScavengeGinvoke6F_b_+0x31c
V  [libjvm.so+0x12e01b4]  HeapWord*ParallelScavengeHeap::failed_mem_allocate(unsigned long)+0x19c;;  __1cUParallelScavengeHeapTfailed_mem_allocate6ML_pnIHeapWord__+0x19c
V  [libjvm.so+0x15ecf74]  void VM_ParallelGCFailedAllocation::doit()+0x124;;  __1cbDVM_ParallelGCFailedAllocationEdoit6M_v_+0x124
V  [libjvm.so+0x161aa7c]  void VM_Operation::evaluate()+0xf4;;  __1cMVM_OperationIevaluate6M_v_+0xf4
V  [libjvm.so+0x16167f0]  void VMThread::evaluate_operation(VM_Operation*)+0x248;;  __1cIVMThreadSevaluate_operation6MpnMVM_Operation__v_+0x248
V  [libjvm.so+0x1617234]  void VMThread::loop()+0x5e4;;  __1cIVMThreadEloop6M_v_+0x5e4
V  [libjvm.so+0x16162d4]  void VMThread::run()+0x124;;  __1cIVMThreadDrun6M_v_+0x124
V  [libjvm.so+0x12a0940]  java_start+0x378;;  java_start+0x378
Comments
Nothing was pushed to the GC repo over the holidays Dec 23 - Jan 02, so nine nightlies ran on the same build. These were fairly clean, a few known bugs showed up here and there, but nothing major. One night though (Dec 26) three tests crashed on the same machine in different tests running different GCs. Of course it is possible that some intermittent bug(s) decided to hit that night on that machine, but since none of these has reproduced since then I'm going to close this one as CNR and blame it on the machine for now.
26-01-2015
This is a nightly failure, so ILW impact and workaround get bumped to high. New ILW = hlh -> p2.
05-01-2015
ILW: impact = high (crash), likelihood = low (debug-only code, one occurrence), workaround = low (-XX:-CheckZapUnusedHeapArea) -> p4.
05-01-2015