JDK-7055355 : JSR 292: crash while throwing WrongMethodTypeException
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: hs21
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris_10
  • CPU: x86
  • Submitted: 2011-06-16
  • Updated: 2012-12-05
  • Resolved: 2011-06-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 JDK 8 Other
7Fixed 8Fixed hs21Fixed
Related Reports
Relates :  
JDK-7047697 - MethodHandle.invokeExact call for wrong method causes VM failure if run with -Xcomp
Description
% /tmp/i586/jdk1.7.0/bin/java -server -XX:MaxInlineSize=150 -XX:InlineSmallCode=3000 -Xbootclasspath/p:/export/ws/7045514/meth.jar -Xbootclasspath/a:jruby.jar -Djruby.native.enabled=false org.jruby.Main -X+C --1.9 bench_etl.rb
VM option 'MaxInlineSize=150'
VM option 'InlineSmallCode=3000'
# To suppress the following error report, specify this argument
# after -XX: or in .hotspotrc:  SuppressErrorAt=/frame.cpp:394
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/tmp/jprt/P1/B/172205.never/source/src/share/vm/runtime/frame.cpp:394), pid=21603, tid=2
#  assert(is_interpreted_frame()) failed: interpreted frame expected
#
# JRE version: 7.0-b145
# Java VM: Java HotSpot(TM) Server VM (21.0-b14-internal-201106151722.never.main_to_comp-fastdebug mixed mode solaris-x86 )
# Core dump written. Default location: /never/tmp/indy-crasher/core or core.21603
#
# An error report file with more information is saved as:
# /never/tmp/indy-crasher/hs_err_pid21603.log
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.sun.com/bugreport/crash.jsp
#
Current thread is 2
Dumping core ...

This also seems to be the cause of the following crash seen with the jck tests:

[Enter:vm.classfmt.atr.atrbsm002.atrbsm00201m1.atrbsm00201m1]
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0xfe0d37f7, pid=15854, tid=11
#
# JRE version: 7.0-b145
# Java VM: Java HotSpot(TM) Server VM (21.0-b14-internal-201106151722.never.main_to_comp compiled mode solaris-x86 )
# Problematic frame:
# V  [libjvm.so+0xd37f7]  void objArrayKlass::oop_follow_contents(oopDesc*)+0x1c7
#
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /export/ws/7045514/work/hs_err_pid15854.log
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.sun.com/bugreport/crash.jsp
#
Abort
Comments
EVALUATION http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/d83ac25d0304
08-07-2011
EVALUATION http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/d83ac25d0304
07-07-2011
EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/38fa55e5e792
18-06-2011
EVALUATION http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/38fa55e5e792
17-06-2011
EVALUATION 7055355: JSR 292: crash while throwing WrongMethodTypeException Reviewed-by: jrose, twisti, bdelsart When throwing a WrongMethodTypeException from a MethodHandle the existing code was pretending it was in the interpreter which worked ok most of the time but would sometimes die when trying to throw with a compiled caller. It could cause asserts in some contexts or result in GC crashes. The fix is to remove the old machinery in favor of the more standard code for throwing exceptions in StubRoutines/SharedRuntime. There was one other use of the old throw machinery but it's in part of check that can never fail since we won't enable method handles unless we have a non-NULL rasie exception method. There's an extra fix in the there to reject lookups of clinit. It isn't critical but it allows all the JCK tests to run without asserting. Tested with failing JCK test and jruby crasher on sparc/x86 with client/server/d64, along with a full run of the invokedynamic JCK tests, the JLI regression tests and the vm.mlvm tests.
16-06-2011
EVALUATION http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/d83ac25d0304
16-06-2011
EVALUATION Ok.
16-06-2011