JDK-6355413 : crash in parallel scavenge on linux/amd64 on PRT test
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 6
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: linux
  • CPU: x86
  • Submitted: 2005-11-25
  • Updated: 2011-01-19
  • Resolved: 2006-03-15
Related Reports
Duplicate :  
JDK-6350066 - Nightly testing and PRT/GCBasher got assert(end >= start,"incorrect constructor arguments")
Description
Sometimes during PRT submission we have following crash on linux/amd64:

java -d64 -server -Xmx384M -XX:+UseParallelGC  GCOld 50 1 20 10 10000

50 megabytes of live storage
1 work units per step
promotion ratio is 1:20
pointer mutation rate is 10
10000 steps
Allocating 152 trees.
  (49804320 bytes)
#
# An unexpected error has been detected by Java Runtime Environment:
#
#  Internal Error (5053394F554E4727454E0E435050020B), pid=22507, tid=1080252784
#
# Java VM: Java HotSpot(TM) 64-Bit Server VM (20051123094139.ni81036.hotspot mixed mode)
# An error report file with more information is saved as hs_err_pid22507.log
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp

 Which is  psYoungGen.cpp:523, 

  522    guarantee((HeapWord*)from_end >= from_space()->top(),
  523              "from end moved into live data");

 Stack trace is like this:
Stack: [0x0000000040535000,0x0000000040636000),  sp=0x0000000040634cd0,  free sp
ace=1023k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x5ae314];;  VMError::report_and_die()+0x224
V  [libjvm.so+0x21a9c6];;  report_fatal(char const*, int, char const*)+0x46
V  [libjvm.so+0x4be2c4];;  PSYoungGen::resize_spaces(unsigned long, unsigned long)+0x2e4
V  [libjvm.so+0x4bde73];;  PSYoungGen::resize(unsigned long, unsigned long)+0x43
V  [libjvm.so+0x486a41];;  ParallelScavengeHeap::resize_young_gen(unsigned long, unsigned long)+0x71
V  [libjvm.so+0x4bbcde];;  PSScavenge::invoke_no_policy(bool*)+0xc0e
V  [libjvm.so+0x4baf6b];;  PSScavenge::invoke(bool*)+0x5b
V  [libjvm.so+0x485d07];;  ParallelScavengeHeap::failed_mem_allocate(bool*, unsigned long, bool)+0x67
V  [libjvm.so+0x5af8e6];;  VM_ParallelGCFailedAllocation::doit()+0x66
V  [libjvm.so+0x5b7cba];;  VM_Operation::evaluate()+0x4a
V  [libjvm.so+0x5b7422];;  VMThread::evaluate_operation(VM_Operation*)+0x82
V  [libjvm.so+0x5b766f];;  VMThread::loop()+0x16f
V  [libjvm.so+0x5b71fe];;  VMThread::run()+0x6e
Comments
EVALUATION The bug was not seen for at least a month since the fix for the similar bug was integrated (6350066). I did analysis of the code that might be the cause of the crush: Assume the young generation is correct and the jvm crashes due to the resizing code. Essential operators for the case 'eden, from, to': to_end = _virtual_space->high(); to_start = to_end - requested_survivor_size; Suppose the 'requested_survivor_size' is so large that 'to_start < from_space()->end()' if (to_start < from_space()->end()) { size_t from_size = from_space()->top() - from_start; ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ this line just calculates live data size, so if heap is correct, then this value is also correct if (from_size == 0) { from_size = alignment; } else { from_size = align_size_up(from_size, alignment); } from_end = from_start + from_size; ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ this line can destroy from space, but it can do this only if 'alignment' is changed which is not the case assert(from_end > from_start, "addition overflow or from_size problem"); guarantee(from_end <= (char*)from_space()->end(), "from_end moved to the right"); to_start = MAX2(from_end, to_start); } guarantee((HeapWord*)from_start <= from_space()->bottom(), "from start moved to the right"); guarantee((HeapWord*)from_end >= from_space()->top(), "from end moved into live data"); Also, to prove my sentence that the reason of the bug is the same as for 6350066 I will cite the heap layout from the crash report. Steve Bohne has recently sent it to me. Heap PSYoungGen total 10112K, used 13440K [0x0000002aaee80000, 0x0000002ab1b50000, 0x0000002ab6e80000) eden space 13376K, 0% used [0x0000002aaee80000,0x0000002aaee80000,0x0000002aafb90000) from space 18014398509478720K, 0% used [0x0000002aafb90000,0x0000002ab08b0000,0x0000002aaf860000) to space 0K, -2147483648% used [0x0000002aaf860000,0x0000002aaf860000,0x0000002aaf860000) PSOldGen total 70144K, used 44677K [0x0000002a9ee80000, 0x0000002aa3300000, 0x0000002aaee80000) object space 70144K, 63% used [0x0000002a9ee80000,0x0000002aa1a21408,0x0000002aa3300000) PSPermGen total 21248K, used 2180K [0x0000002a99c80000, 0x0000002a9b140000, 0x0000002a9ee80000) object space 21248K, 10% used [0x0000002a99c80000,0x0000002a99ea13e8,0x0000002a9b140000) The heap is broken before resizing. So I closed the bug as duplicate.
15-03-2006