Indy crash

Tom Rodriguez tom.rodriguez at oracle.com
Wed Jun 15 14:18:52 PDT 2011 

On Jun 15, 2011, at 11:47 AM, Christian Thalinger wrote:

> On Jun 15, 2011, at 8:08 PM, Charles Oliver Nutter wrote:
>> FWIW, I only get the crash on my MLVM build if I pass these flags to JVM:
>> 
>> -XX:MaxInlineSize=150 -XX:InlineSmallCode=3000
>> 
>> See README and use jruby.jar from this repo to make it easier:
>> 
>> https://github.com/headius/indy-crasher
>> 
>> I'll try that x64 build in a moment.
> 
> Indeed I get a crash on Solaris and Linux using JDK7 b145.  But with a bundle containing the latest two fixes all looks good:
> 
> $ /java/re/jdk/7/promoted/all/b145/binaries/solaris-x64/bin/java -showversion -d64 -XX:MaxInlineSize=150 -XX:InlineSmallCode=3000 -Xbootclasspath/a:jruby.jar -Djruby.native.enabled=false org.jruby.Main -X+C --1.9 bench_etl.rb
> java version "1.7.0-ea"
> Java(TM) SE Runtime Environment (build 1.7.0-ea-b145)
> Java HotSpot(TM) 64-Bit Server VM (build 21.0-b15, mixed mode)
> 
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  SIGSEGV (0xb) at pc=0xfffffd7ffe9bf980, pid=649, tid=2
> #
> # JRE version: 7.0-b145
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (21.0-b15 mixed mode solaris-amd64 compressed oops)
> # Problematic frame:
> # V  [libjvm.so+0xdbf980]  int methodOopDesc::validate_bci_from_bcx(long)const+0x24
> #
> # 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:
> # /home/ct232829/mlvm/jruby/indy-crasher/hs_err_pid649.log
> Phoning home... 
> Using server: 10.161.186.18, port 4711
> #
> # If you would like to submit a bug report, please visit:
> #   http://bugreport.sun.com/bugreport/crash.jsp
> #
> Abort
> 
> $ java -showversion -d64 -XX:MaxInlineSize=150 -XX:InlineSmallCode=3000 -Xbootclasspath/a:jruby.jar -Djruby.native.enabled=false org.jruby.Main -X+C --1.9 bench_etl.rb
> java version "1.7.0-ea"
> Java(TM) SE Runtime Environment (build 1.7.0-ea-b145)
> Java HotSpot(TM) 64-Bit Server VM (build 21.0-b14-internal-201106142151.never.7052219, mixed mode)

How are you injecting the latest meth.jar here?  I don't see it in the command line.  If I run the 7052219 jvm with b145 then it does pass but if I add in meth.jar then I see a crash with WrongMethodTypeException.  I think there are still some bugs with throwing these and maybe the very latest JDK changes are throwing it in cases where we wouldn't before.  I just reproduced a similar crash when running the very latest JCK tests that I'm investigating as well.

The stack trace at the failing point in the jruby case is this:

 1 - frame( sp=0xfc64e0c8, unextended_sp=0xfc64e0d0, fp=0xfc64e0d0, pc=0xf978d5cc)
java.lang.invoke.MethodHandle.invokeExact
 2 - frame( sp=0xfc64e0c8, unextended_sp=0xfc64e0d0, fp=0xfc64e0d0, pc=0xf978d5cc)
never.tmp.indy_minus_crasher.date.format.method__4$RUBY$method_missing(/never/tmp/indy-crasher/date/format.rb:121)
 3 - frame( sp=0xfc64e0c8, unextended_sp=0xfc64e0d0, fp=0xfc64e0d0, pc=0xf978d5cc)
never$tmp$indy_minus_crasher$date$format$method__4$RUBY$method_missing.call(never$tmp$indy_minus_crasher$date$format$method__4$RUBY$method_missing:65\
535)
 4 - frame( sp=0xfc64e0c8, unextended_sp=0xfc64e0d0, fp=0xfc64e0d0, pc=0xf978d5cc)
org.jruby.javasupport.util.RuntimeHelpers$MethodMissingMethod.call(RuntimeHelpers.java:497)
 5 - frame( sp=0xfc64e160, unextended_sp=0xfc64e160, fp=0xfc64e1bc, pc=0xf9403133)
org.jruby.internal.runtime.methods.DynamicMethod.call(DynamicMethod.java:213)
 6 - frame( sp=0xfc64e1c4, unextended_sp=0xfc64e1c4, fp=0xfc64e200, pc=0xf9403133)
org.jruby.runtime.invokedynamic.InvokeDynamicSupport.callMethodMissing(InvokeDynamicSupport.java:1820)
 7 - frame( sp=0xfc64e208, unextended_sp=0xfc64e208, fp=0xfc64e240, pc=0xf9403133)
org.jruby.runtime.invokedynamic.InvokeDynamicSupport.invocationFallback(InvokeDynamicSupport.java:455)
 8 - frame( sp=0xfc64e248, unextended_sp=0xfc64e258, fp=0xfc64e28c, pc=0xf94036b1)
never.tmp.indy_minus_crasher.date.format.method__40$RUBY$_parse(/never/tmp/indy-crasher/date/format.rb:1035)

And the exception message would have been "WrongMethodTypeException: (Z)Ljava/lang/invoke/MethodHandle; cannot be called as (Z)Ljava/lang/Object;"

It looks like it's part of some selectAlternative code.  I don't know if there's enough there for you to understand what it's complaining about.

The underlying problem is that we're aren't throwing the WMT correctly when the caller is compiled and bad things occur as a result.

tom

> 
> Transform time : 101
> 
> Can you confirm that?
> 
> -- Christian
> 
>> 
>> On Wed, Jun 15, 2011 at 7:38 AM, Christian Thalinger
>> <christian.thalinger at oracle.com> wrote:
>>> On Jun 15, 2011, at 6:09 AM, Charles Oliver Nutter wrote:
>>>> Still crashing! See previous email for hs dumpfile, command-line, and
>>>> script, with link to data in the script.
>>> 
>>> I can not reproduce this crash on either Linux nor Solaris.  Here is a recent Linux x64 product build:
>>> 
>>> http://cr.openjdk.java.net/~twisti/linux_x64_2.6-product.zip
>>> 
>>> Could you please try that one?
>>> 
>>> -- Christian
>>> 
>>>> 
>>>> - Charlie
>>>> 
>>>> On Tue, Jun 14, 2011 at 10:46 PM, Charles Oliver Nutter
>>>> <headius at headius.com> wrote:
>>>>> On Tue, Jun 14, 2011 at 10:14 PM, John Rose <john.r.rose at oracle.com> wrote:
>>>>>> This looks like a failure fixed very recently (6/12) by the final version of meth-exc-7047697.patch.
>>>>>> 
>>>>>> Please let me know ASAP if the latest version of that patch *fails* to fix your crash!
>>>>> 
>>>>> Doing an updated build from MLVM, where 'hotspot' tip shows:
>>>>> 
>>>>> ~/projects/mlvm/patches/hotspot ➔ hg log | head -5
>>>>> changeset:   353:c04ab8f822b1
>>>>> tag:         tip
>>>>> user:        jrose
>>>>> date:        Tue Jun 14 18:34:58 2011 -0700
>>>>> summary:     meth: update to hotspot-comp
>>>>> 
>>>>> Will report back shortly.
>>>>> 
>>>>> - Charlie
>>>>> 
>>>> _______________________________________________
>>>> mlvm-dev mailing list
>>>> mlvm-dev at openjdk.java.net
>>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>>> 
>>> 
>>> _______________________________________________
>>> mlvm-dev mailing list
>>> mlvm-dev at openjdk.java.net
>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>>> 
>> _______________________________________________
>> mlvm-dev mailing list
>> mlvm-dev at openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
> 
> 
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

More information about the mlvm-dev mailing list