United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-7043461 VM crashes in void LinkResolver::runtime_resolve_virtual_method
JDK-7043461 : VM crashes in void LinkResolver::runtime_resolve_virtual_method

Details
Type:
Bug
Submit Date:
2011-05-10
Status:
Closed
Updated Date:
2011-07-29
Project Name:
JDK
Resolved Date:
2011-07-18
Component:
hotspot
OS:
solaris,generic
Sub-Component:
runtime
CPU:
sparc,generic
Priority:
P2
Resolution:
Fixed
Affected Versions:
hs21,7
Fixed Versions:
hs21 (b13)

Related Reports
Backport:
Duplicate:
Duplicate:
Relates:

Sub Tasks

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

http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/3d2ab563047a
                                     
2011-05-12
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.
                                     
2011-05-12



Hardware and Software, Engineered to Work Together