JDK-7043461 : VM crashes in void LinkResolver::runtime_resolve_virtual_method
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: hs21,7
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: generic,solaris
  • CPU: generic,sparc
  • Submitted: 2011-05-10
  • 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
Related Reports
Duplicate :  
Duplicate :  
Relates :  
Description
VM could crash while debugging.

JDK: Java(TM) SE Runtime Environment (build 1.7.0-ea-b141)
VM: Java HotSpot(TM) Client VM (build 21.0-b12-internal-201105062148.et151817.hs21-b12-snapshot, mixed mode, sharing)

head of hs_err is:
;; Using jvm: "/export/local/common/jdk/baseline/solaris-sparc/jre/lib/sparc/client/libjvm.so"
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0xfeccfb68, pid=25824, tid=2
#
# JRE version: 7.0-b141
# Java VM: Java HotSpot(TM) Client VM (21.0-b12-internal-201105062148.et151817.hs21-b12-snapshot compiled mode solaris-sparc )
# Problematic frame:
# V  [libjvm.so+0x4cfb68]  void LinkResolver::runtime_resolve_virtual_method(CallInfo&,methodHandle,KlassHandle,Handle,KlassHandle,bool,Thread*)+0x1ec
#
# Core dump written. Default location: /export/local/49709.HSX.PIT.VM+solaris-sparc_vm__client_compd_nsk.jdi.testlist/results/ResultDir/tc04x001/core or core.25824
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.sun.com/bugreport/crash.jsp
#

Comments
EVALUATION 7043461: VM crashes in void LinkResolver::runtime_resolve_virtual_method Reviewed-by: kvn, coleenp The original fix for 7009361, JSR 292 Invalid value on stack on solaris-sparc with -Xcomp, has had a bunch of fallout with several follow on fixes. I'm abandoning the original fix as there are issues with how popframe works that I can't easily resolve. I had originally considered a fix that passed the callers notion of the number of parameters down the call chain down to layout activation so the correct top of stack could be computed but the other fix seemed more straightforward and appeared to work ok initially. I've now gone back to that fix. So I anti-delta'ed the original fix in templateInterpreter_sparc.cpp and passed the callers parameters count around to all the places it's needed. This required touching a lot of shared code to pass it through. Each platform had it's own copy of the size_activation wrapper and moved that into shared code. x86 doesn't have to fix use the new value since they don't attempt to place the locals next to the caller stack. The fix now has no effect on how deopt works except in the case where an invokedynamic is on the stack. Tested with all failing test cases from 7009361, 7043461, 7042052, and 7043473. I'm currently running the larger suites that those failing tests were part of to ensure there aren't other issues.
12-05-2011

EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/3d2ab563047a
12-05-2011