Navigation Menu

Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

JVM segfault with 9K and -noverify #2566

Closed
grddev opened this issue Feb 5, 2015 · 5 comments
Closed

JVM segfault with 9K and -noverify #2566

grddev opened this issue Feb 5, 2015 · 5 comments
Labels
ir jit JRuby 9000
Milestone
Invalid or Duplicate

Comments

@grddev
Copy link
Contributor

grddev commented Feb 5, 2015

I tried running the test-suite of one of our larger code-bases against jruby-head, and to my surprise the JVM suddenly segfaulted halfway through.

After some digging, I realized that the crash only happened when running with the option -J-noverify. At some point I put this flag into JRUBY_OPTS in order to improve start-up time. If I remove this flag, I see no crash, and no sign of any problem whatsoever. Similarly, if I run in jruby-1.7 (with or without -J-noverify) everything works well. Is this flag no longer supported by jruby-head?

I'm guessing some part of the new bytecode generation is the cause for the particular issue, and to that end I spent some time reducing thousands of lines of code to the following short snippet. With this snippet I can consistently reproduce the issue:

instance_eval do
  begin
    raise
  rescue
    nil
  ensure
    nil
  end
end

Beyond this point, I wasn't able to remove any more parts while retaining the segfault. I'm guessing that the next step to understand what is going on here, but I wouldn't really know where to start.
@subbuss subbuss added this to the 9.0.0.0.pre2 milestone Feb 15, 2015
@headius
Copy link
Member

headius commented Apr 17, 2015

Ok, this probably means there's some bad bytecode being jitted. Could you do a run with the following flags (and noverify OFF) so we might see the problem with the bytecode?

jruby -Xjit.logging=true -Xjit.logging.verbose=true <your app>

@headius headius modified the milestones: 9.0.0.0.rc1, 9.0.0.0.pre2 Apr 17, 2015
@headius
Copy link
Member

headius commented Apr 17, 2015

BTW, JRuby's normal command line does boot JRuby itself into the boot classloader, skipping verification. Turning on noverify would only help libraries your app loads or other JVM bytecode loaded after JRuby has started up.

Also look into the --dev flag for better startup times.

@grddev
Copy link
Contributor Author

grddev commented Apr 19, 2015

I put the above failing code into noverify-test.rb, and ran jruby -Xjit.logging=true -Xjit.logging.verbose=true noverify-test.rb, which produced the following:

2015-04-19T08:47:53.128+02:00: Ruby: failed to compile target script noverify-test.rb: failed to compile script noverify-test.rb
org.jruby.compiler.NotCompilableException: failed to compile script noverify-test.rb
    at org.jruby.ir.Compiler.execute(Compiler.java:62)
    at org.jruby.ir.Compiler.execute(Compiler.java:30)
    at org.jruby.ir.IRTranslator.execute(IRTranslator.java:42)
    at org.jruby.Ruby.tryCompile(Ruby.java:808)
    at org.jruby.Ruby.precompileCLI(Ruby.java:766)
    at org.jruby.Ruby.runNormally(Ruby.java:740)
    at org.jruby.Ruby.runFromMain(Ruby.java:573)
    at org.jruby.Main.doRunFromMain(Main.java:404)
    at org.jruby.Main.internalRun(Main.java:299)
    at org.jruby.Main.run(Main.java:226)
    at org.jruby.Main.main(Main.java:198)
Caused by: java.lang.VerifyError: Instruction type does not match stack map
Exception Details:
  Location:
    noverify_minus_test.RUBY$block$\=noverify-test\,rb$0(Lorg/jruby/runtime/ThreadContext;Lorg/jruby/parser/StaticScope;Lorg/jruby/runtime/builtin/IRubyObject;[Lorg/jruby/runtime/builtin/IRubyObject;Lorg/jruby/runtime/Block;Ljava/lang/String;Lorg/jruby/runtime/Block$Type;)Lorg/jruby/runtime/builtin/IRubyObject; @42: nop
  Reason:
    Current frame's stack size doesn't match stackmap.
  Current Frame:
    bci: @42
    flags: { }
    locals: { 'org/jruby/runtime/ThreadContext', 'org/jruby/parser/StaticScope', 'org/jruby/runtime/builtin/IRubyObject', '[Lorg/jruby/runtime/builtin/IRubyObject;', 'org/jruby/runtime/Block', 'java/lang/String', 'org/jruby/runtime/Block$Type', 'org/jruby/runtime/DynamicScope', 'org/jruby/runtime/builtin/IRubyObject', 'org/jruby/runtime/builtin/IRubyObject', 'org/jruby/runtime/builtin/IRubyObject', 'org/jruby/runtime/builtin/IRubyObject', 'org/jruby/runtime/builtin/IRubyObject' }
    stack: { }
  Stackmap Frame:
    bci: @42
    flags: { }
    locals: { }
    stack: { 'java/lang/Throwable' }
  Bytecode:
    0x0000000: 2ab6 000f 3a07 2ab4 0013 3a08 1908 3a09
    0x0000010: 1908 3a0a 1908 3a0b 1908 3a0c 2ab4 0017
    0x0000020: b600 1d12 1fb6 0025 3a0b 0000 0000 0000
    0x0000030: 00bf 0000 00bf 1908 b000 0000 00bf 3a0c
    0x0000040: 2a2a b400 17b6 003f 1241 1242 b800 463a
    0x0000050: 092a 1909 190c b800 4a3a 0a19 0ab9 0050
    0x0000060: 0100 9a00 1d19 0cbf 3a0b 190b bf3a 082a
    0x0000070: 2b19 0719 0819 06b8 0054 3a0b 190b b02a
    0x0000080: b400 17b6 001d 121f 190b b600 5857 2ab4
    0x0000090: 0013 3a08 a7ff a2
  Exception Handler Table:
    bci [62, 101] => handler: 104
    bci [101, 104] => handler: 104
    bci [106, 109] => handler: 109
    bci [127, 148] => handler: 104
  Stackmap Table:
    full_frame(@42,{},{Object[#39]})
    same_locals_1_stack_item_frame(@50,Object[#39])
    full_frame(@54,{Object[#11],Object[#109],Object[#76],Object[#110],Object[#112],Object[#114],Object[#116],Object[#118],Object[#76],Object[#76],Object[#76],Object[#76],Object[#39]},{})
    full_frame(@57,{},{Object[#39]})
    full_frame(@62,{Object[#11],Object[#109],Object[#76],Object[#110],Object[#112],Object[#114],Object[#116],Object[#118],Object[#76],Object[#76],Object[#76],Object[#76],Object[#76]},{Object[#39]})
    full_frame(@104,{Object[#11],Object[#109],Object[#76],Object[#110],Object[#112],Object[#114],Object[#116],Object[#118],Object[#76],Object[#76],Object[#76],Object[#76],Object[#4]},{Object[#39]})
    full_frame(@109,{Object[#11],Object[#109],Object[#76],Object[#110],Object[#112],Object[#114],Object[#116],Object[#118],Object[#76],Object[#76],Object[#76],Object[#39],Object[#4]},{Object[#39]})
    full_frame(@127,{Object[#11],Object[#109],Object[#76],Object[#110],Object[#112],Object[#114],Object[#116],Object[#118],Object[#76],Object[#76],Object[#76],Object[#76],Object[#39]},{})

    at java.lang.Class.getDeclaredFields0(Native Method)
    at java.lang.Class.privateGetDeclaredFields(Class.java:2575)
    at java.lang.Class.getField0(Class.java:2967)
    at java.lang.Class.getField(Class.java:1693)
    at org.jruby.ir.targets.JVMVisitor.defineFromBytecode(JVMVisitor.java:91)
    at org.jruby.ir.Compiler.execute(Compiler.java:54)
    ... 10 more

This was using 0902cd3

jruby 9.0.0.0-SNAPSHOT (2.2.2) 2015-04-19 0902cd3 Java HotSpot(TM) 64-Bit Server VM 25.25-b02 on 1.8.0_25-b17 +jit [darwin-x86_64]

A similar error was generated using a4e929d, and JDK 1.7, which was the version used when this was initially reported.

@grddev
Copy link
Contributor Author

grddev commented May 9, 2015

When trying the same thing today (on eeddbc1), the problem was fixed. I ran a git bisect to figure out what fixed it, and it pointed me towards d6c5355. Thus, this issue seems to in-fact be an instance of #2910.

@enebo
Copy link
Member

enebo commented Jul 1, 2015

Marking as duplicate of #2910

@enebo enebo closed this as completed Jul 1, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
ir jit JRuby 9000
Projects
None yet
Milestone
Invalid or Duplicate
Development

No branches or pull requests
4 participants
@headius @enebo @subbuss @grddev