JDK-7057587 : JSR 292 - crash with jruby in test/test_respond_to.rb
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: hs21,hs22
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic,solaris_10
  • CPU: generic,x86
  • Submitted: 2011-06-21
  • Updated: 2012-12-05
  • Resolved: 2011-06-25
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
Duplicate :  
JDK-7057285 - JSR 292: PrintInlining prints flat trees with discounted MH calls
Description
I have seen this crash in several ways and all involved a GuardWithCatch, suggesting a problem with exception dispatch.  It appears that the last sp value is being replaced with an oop sometimes which moves the stack into the Java heap and various kinds of crashes result.
From Christian:

I have bad news:  I found a C1 crasher today and I don't know yet what causes it.  It happens with both the promoted b146 drop and self-built Hotspot with John's latest patch applied.  I can reproduce it with product and fastdebug but no luck with debug yet.

Here is the output of a debugging session:

ct232829@intelsdv07:~/mlvm/jruby$ bin/jruby.sh -J-XX:+ShowMessageBoxOnError -J-showversion --client test/test_respond_to.rb 
VM option '+ShowMessageBoxOnError'
java version "1.7.0-fastdebug"
Java(TM) SE Runtime Environment (build 1.7.0-fastdebug-b146)
Java HotSpot(TM) Client VM (build 21.0-b14-internal-fastdebug, mixed mode)

Loaded suite test/test_respond_to
Started
.==============================================================================
Unexpected Error
------------------------------------------------------------------------------
SIGSEGV (0xb) at pc=0xf8d2c0c4, pid=19220, tid=15

Do you want to debug the problem?

To debug, run 'dbx - 19220'; then switch to thread 15
Enter 'yes' to launch dbx automatically (PATH must include dbx)
Otherwise, press RETURN to abort...
==============================================================================
Comments
EVALUATION http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/aabf25fa3f05
08-07-2011
EVALUATION http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/aabf25fa3f05
07-07-2011
EVALUATION http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/393e144bb99b
23-06-2011
EVALUATION http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/aabf25fa3f05
22-06-2011
SUGGESTED FIX diff -r d83ac25d0304 src/share/vm/code/nmethod.cpp --- a/src/share/vm/code/nmethod.cpp +++ b/src/share/vm/code/nmethod.cpp @@ -1832,7 +1832,8 @@ if (!method()->is_native()) { SimpleScopeDesc ssd(this, fr.pc()); Bytecode_invoke call(ssd.method(), ssd.bci()); - bool has_receiver = call.has_receiver(); + // invokedynamic has a receiver in the signature at this point + bool has_receiver = !call.is_invokestatic(); Symbol* signature = call.signature(); fr.oops_compiled_arguments_do(signature, has_receiver, reg_map, f); }
22-06-2011
EVALUATION The problem is that when we GC during resolution at an unresolved invokedynamic call site the receiver is skipped which leads to problems later. The bug arises from the fact that the receiver is kind of implicit for invokedynamic call sites.
22-06-2011