Indy crash

Christian Thalinger christian.thalinger at oracle.com
Thu Jun 16 03:47:28 PDT 2011 

On Jun 15, 2011, at 11:18 PM, Tom Rodriguez wrote:
> 
> 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 forgot to add it.  Using John's latest meth.jar results in the expected crash.  Applying your fix throws the WMTE, in this case (bench_etl.rb):

MethodHandle.java:-1:in `invokeExact': java.lang.invoke.WrongMethodTypeException: (Lorg/jruby/runtime/ThreadContext;Lorg/jruby/runtime/builtin/IRubyObject;Lorg/jruby/runtime/builtin/IRubyObject;Ljava/lang/String;Lorg/jruby/runtime/builtin/IRubyObject;Lorg/jruby/runtime/builtin/IRubyObject;)Z cannot be called as (Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Z

-- Christian

>  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
> 
> _______________________________________________
> 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