JDK-7043040 : JSR292: JRuby bench/shootout/binarytrees.ruby-2.ruby SEGV: constantPoolKlass::oop_follow_contents
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: hs21
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2011-05-09
  • Updated: 2011-07-29
  • Resolved: 2011-07-18
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 7 Other
7Fixed hs21Fixed
Description
http://mail.openjdk.java.net/pipermail/mlvm-dev/2011-May/002978.html

$ bin/jruby.sh --server bench/shootout/binarytrees.ruby-2.ruby 15
stretch tree of depth 16         check: -1
65536    trees of depth 4        check: -65536
16384    trees of depth 6        check: -16384
4096     trees of depth 8        check: -4096
1024     trees of depth 10       check: -1024
256      trees of depth 12       check: -256
64       trees of depth 14       check: -64
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0xfd2c148a, pid=214384, tid=6
#
# JRE version: 7.0-b141
# Java VM: Java HotSpot(TM) Server VM (21.0-b11-fastdebug mixed mode solaris-x86 )
# Problematic frame:
# V  [libjvm.so+0xac148a]  void constantPoolKlass::oop_follow_contents(oop)+0x4a6


Stack: [0xd5885000,0xd5905000],  sp=0xd59045d0,  free space=509k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0xac148a]  void constantPoolKlass::oop_follow_contents(oop)+0x4a6
V  [libjvm.so+0x16581fa]  void MarkSweep::follow_stack()+0x1fa
V  [libjvm.so+0x194f51d]  void PSMarkSweep::mark_sweep_phase1(bool)+0x125
V  [libjvm.so+0x194dae5]  void PSMarkSweep::invoke_no_policy(bool)+0x509
V  [libjvm.so+0x1992d19]  void PSScavenge::invoke()+0x205
V  [libjvm.so+0x18ac470]  HeapWord*ParallelScavengeHeap::failed_mem_allocate(unsigned,bool)+0x120
V  [libjvm.so+0x1cf2398]  void VM_ParallelGCFailedAllocation::doit()+0xc4
V  [libjvm.so+0x1d19bba]  void VM_Operation::evaluate()+0xe2
V  [libjvm.so+0x1d17e50]  void VMThread::loop()+0x788
V  [libjvm.so+0x1d17059]  void VMThread::run()+0xc1
V  [libjvm.so+0x184e573]  java_start+0x6fb
C  [libc.so.1+0xbb2dc]  _thrp_setup+0x9d
C  [libc.so.1+0xbb580]  _lwp_start+0x0

VM_Operation (0xfc5fbfd0): ParallelGCFailedAllocation, mode: safepoint, requested by thread 0x0809b000
Comments
EVALUATION 7043040: JSR292: JRuby bench/shootout/binarytrees.ruby-2.ruby SEGV: constantPoolKlass::oop_follow_contents Reviewed-by: kvn, ysr The logic in oop_push_constants was skipping JVM_CONSTANT_Object entries which would cause corruption in later GCs. The fix is to use is_pointer_entry to identify roots like all the other visitor. The verify_on method was also too weak so it missed the problem when run with the verify GC flags. Tested with failing test from report.
11-05-2011
EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/69c94f488271
11-05-2011
EVALUATION It works with UseSerialGC and UseG1GC. *** (#1 of 1): [ UNSAVED ] ###@###.###
09-05-2011