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.thalin...@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 >>>>> <head...@headius.com> wrote: >>>>>> On Tue, Jun 14, 2011 at 10:14 PM, John Rose <john.r.r...@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@openjdk.java.net >>>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >>>> >>>> >>>> _______________________________________________ >>>> mlvm-dev mailing list >>>> mlvm-dev@openjdk.java.net >>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >>>> >>> _______________________________________________ >>> mlvm-dev mailing list >>> mlvm-dev@openjdk.java.net >>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >> >> >> _______________________________________________ >> mlvm-dev mailing list >> mlvm-dev@openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev@openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
