The ShowMessageBox option also gave me the option of launching gdb. I'm not a gdb expert, but "bt" produced this:
(gdb) bt #0 0x96ebf3ae in __semwait_signal () #1 0x96f04398 in pthread_join$UNIX2003 () #2 0x0000668b in ContinueInNewThread0 () #3 0x0000440e in JLI_Launch () #4 0x0000d388 in main () Trying now to see if I can view stacks for other threads or something. On Tue, Aug 4, 2009 at 10:24 PM, Charles Oliver Nutter<head...@headius.com> wrote: > Here's the output with the verify flags on: > > ~/projects/jruby ➔ jruby -J-XX:+UnlockDiagnosticVMOptions > -J-XX:+VerifyBeforeGC -J-XX:+VerifyAfterGC > -J-Djruby.compile.invokedynamic -J-XX:+EnableInvokeDynamic > bench/bench_fib_recursive.rb 100 > [Verifying threads permgen tenured generation def new generation > remset ref_proc syms strs zone dict hand C-heap ] > VerifyBeforeGC:[Verifying threads permgen tenured generation def new > generation remset ref_proc syms strs zone dict hand C-heap ] > VerifyAfterGC:[Verifying threads permgen tenured generation def new > generation remset ref_proc syms strs zone dict hand C-heap ] > VerifyBeforeGC:[Verifying threads permgen tenured generation def new > generation remset ref_proc syms strs zone dict hand C-heap ] > VerifyAfterGC:[Verifying threads permgen tenured generation def new > generation remset ref_proc syms strs zone dict hand C-heap ] > VerifyBeforeGC:[Verifying threads permgen tenured generation def new > generation remset ref_proc syms strs zone dict hand C-heap ] > VerifyAfterGC:[Verifying threads permgen tenured generation def new > generation remset ref_proc syms strs zone dict hand C-heap ] > VerifyBeforeGC:[Verifying threads # > > The hs_err file is attached. I do not have pstack on OS X...do you > know what the equivalent would be? > > On Tue, Aug 4, 2009 at 8:56 PM, <y.s.ramakris...@sun.com> wrote: >> The crash is in GC. Together with yr conjecture that the crash happens >> after a while when you expect the method to have been jitted, this might >> imply that the jit is not correctly conveying to GC where the >> references in jitted frames are or is not marking cards for the >> generational collector correctly, or GC isn't looking at all the >> slots it should be looking at or .... (But that is a long assumption.) >> The funny part about "running long enough" is that the hs_err log >> says the crash occurred after 0 seconds, so the VM is probably >> not correctly printing the time it's been running. >> >> I'd suggest running the JVM with the options -XX:+VerifyBeforeGC and >> -XX:+VerifyAfterGC >> to perhaps catch the problem sooner or get closer to the root cause. >> If you run with the additional JVM option -XX:+ShowMessageBoxOnError >> you might be able to pstack the process and get some info. (Or >> use the hs_err script to decode the stack trace from the hs_err log.) >> >> -- ramki >> >> On 08/04/09 18:07, Charles Oliver Nutter wrote: >>> I can't seem to catch a break. My local build and Attila's build still >>> both crash for me. There's got to be something about my environment >>> that's different, eh? >>> >>> As before, interpreter runs fine. Anything that runs long enough to >>> jit seems to crash. I've attached the latest log. >>> >>> On Tue, Aug 4, 2009 at 7:58 PM, Charles Oliver >>> Nutter<head...@headius.com> wrote: >>>> On Tue, Aug 4, 2009 at 4:17 PM, Attila Szegedi<szege...@gmail.com> wrote: >>>>> I can now confirm that it indeed does work with jruby-1.4.0dev that >>>>> indeed emits invokedynamic. >>>>> >>>>> The only catch is, it's very slow with invokedynamic, something that >>>>> Christian also mentioned. >>>> The fact that these numbers are so bad and even degrade shows me that >>>> although it's compiling indy, it's not eliminating the handles (which >>>> is true, the inlining and handle-walking stuff is not ready yet). So >>>> it's got many layers of polymorphic calls, probably some argument >>>> boxing and unboxing, and basically a ton more overhead than our >>>> heavily tuned non-indy call path. I'm confident in the Hotspot guys :) >>>> >>>> Just wanted to make sure anyone watching didn't think this was the >>>> best it would get... >>>> >>>>> MacBook-Pro-Ati:jruby-1.4.0dev aszegedi$ bin/jruby --server -J- >>>>> Djruby.compile.invokedynamic=true -J-XX:+EnableInvokeDynamic bench/ >>>>> bench_fib_recursive.rb 15 >>>>> 2.993000 0.000000 2.993000 ( 2.915000) >>>>> 2.720000 0.000000 2.720000 ( 2.720000) >>>>> 2.773000 0.000000 2.773000 ( 2.773000) >>>>> 2.712000 0.000000 2.712000 ( 2.712000) >>>>> 3.057000 0.000000 3.057000 ( 3.057000) >>>>> 3.183000 0.000000 3.183000 ( 3.184000) >>>>> 3.167000 0.000000 3.167000 ( 3.167000) >>>>> 3.145000 0.000000 3.145000 ( 3.145000) >>>>> 3.249000 0.000000 3.249000 ( 3.249000) >>>>> 3.160000 0.000000 3.160000 ( 3.160000) >>>>> 3.104000 0.000000 3.104000 ( 3.104000) >>>>> 3.152000 0.000000 3.152000 ( 3.153000) >>>>> 3.172000 0.000000 3.172000 ( 3.171000) >>>>> 3.111000 0.000000 3.111000 ( 3.111000) >>>>> 3.201000 0.000000 3.201000 ( 3.201000) >>>>> MacBook-Pro-Ati:jruby-1.4.0dev aszegedi$ bin/jruby --server bench/ >>>>> bench_fib_recursive.rb 15 >>>>> 0.523000 0.000000 0.523000 ( 0.481000) >>>>> 0.292000 0.000000 0.292000 ( 0.291000) >>>>> 0.279000 0.000000 0.279000 ( 0.278000) >>>>> 0.283000 0.000000 0.283000 ( 0.283000) >>>>> 0.284000 0.000000 0.284000 ( 0.284000) >>>>> 0.292000 0.000000 0.292000 ( 0.292000) >>>>> 0.289000 0.000000 0.289000 ( 0.289000) >>>>> 0.286000 0.000000 0.286000 ( 0.287000) >>>>> 0.285000 0.000000 0.285000 ( 0.285000) >>>>> 0.285000 0.000000 0.285000 ( 0.285000) >>>>> 0.289000 0.000000 0.289000 ( 0.290000) >>>>> 0.282000 0.000000 0.282000 ( 0.282000) >>>>> 0.290000 0.000000 0.290000 ( 0.290000) >>>>> 0.293000 0.000000 0.293000 ( 0.293000) >>>>> 0.285000 0.000000 0.285000 ( 0.284000) >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> 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
