United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-7057587 JSR 292 - crash with jruby in test/test_respond_to.rb
JDK-7057587 : JSR 292 - crash with jruby in test/test_respond_to.rb

Details
Type:
Bug
Submit Date:
2011-06-21
Status:
Resolved
Updated Date:
2012-12-05
Project Name:
JDK
Resolved Date:
2011-06-25
Component:
hotspot
OS:
generic,solaris_10
Sub-Component:
compiler
CPU:
x86,generic
Priority:
P2
Resolution:
Fixed
Affected Versions:
hs21,hs22
Fixed Versions:
hs21 (b17)

Related Reports
Backport:
Backport:
Backport:
Duplicate:

Sub Tasks

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
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);
   }
                                     
2011-06-22
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.
                                     
2011-06-22
EVALUATION

http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/aabf25fa3f05
                                     
2011-06-22
EVALUATION

http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/393e144bb99b
                                     
2011-06-23
EVALUATION

http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/aabf25fa3f05
                                     
2011-07-07
EVALUATION

http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/aabf25fa3f05
                                     
2011-07-08



Hardware and Software, Engineered to Work Together