Details

    • Type: Bug Bug
    • Status: Resolved Resolved
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: JRuby 1.7.0.pre1
    • Fix Version/s: JRuby 1.7.0.pre1
    • Component/s: Interpreter
    • Labels:
      None
    • Environment:
      OSX 10.6.8, Java7u2
    • Number of attachments :
      0

      Description

      Download this file. It's a tarball containing 2 gems (ffi-rzmq and zmqmachine) and a C library that is loaded via FFI. There is also a script (install_me) that will ask for sudo permission to install the C lib to /usr/local/lib.

      file: http://dl.dropbox.com/u/44434337/jruby_ffi.tgz

      After running 'install_me' there will be an unpacked gem directory for zmqmachine.

      % cd zmqmachine-0.7.1/examples
      % jruby pub_sub.rb

      This should result in a spectacular backtrace complaining about a NoMethodError for some FFI function.

      https://gist.github.com/ec1065df39561c46b1ff

      Interestingly, this same code runs fine on Windows (though the JRuby master is from Friday, 20111216).

      Trying to run jruby master with compile.mode=OFF and/or compile.invokedynamic=false has no effect. It still crashes though the backtraces will be different.

      The line it crashes on is a call to an FFI-wrapped C function.

        Activity

        Hide
        Chuck Remes added a comment -

        BTW, tried to reduce this unsuccessfully. I suspect my attempts to repro a smaller version failed because there is some race condition and/or other moving part that only gets triggered on this more complex project. I can load ffi-rzmq by itself and run the FFI attached functions without incident. Doing the same work via zmqmachine blows it up.

        Of course, this all works fine with 1.6.x.

        Show
        Chuck Remes added a comment - BTW, tried to reduce this unsuccessfully. I suspect my attempts to repro a smaller version failed because there is some race condition and/or other moving part that only gets triggered on this more complex project. I can load ffi-rzmq by itself and run the FFI attached functions without incident. Doing the same work via zmqmachine blows it up. Of course, this all works fine with 1.6.x.
        Hide
        Wayne Meissner added a comment - - edited

        Chuck, thanks for trying this out.

        It is indeed a bug in jffi (the low level lib jruby uses for implementing FFI).

        The reason it isn't occurring on windows, is due to optimisations.
        i.e. on windows it is:

        if (isWindows()) { 
           // use old slow path
        } else {
           // generate optimised bytecode/x86 assembly
        }
        

        Should be fixed now in jruby-master.

        btw, one reason you might not have been able to reproduce on a cut-down codeset is because of the JIT threshold
        specifying -Xffi.compile.threshold=1 should make all FFI functions JIT on first use.

        Show
        Wayne Meissner added a comment - - edited Chuck, thanks for trying this out. It is indeed a bug in jffi (the low level lib jruby uses for implementing FFI). The reason it isn't occurring on windows, is due to optimisations. i.e. on windows it is: if (isWindows()) { // use old slow path } else { // generate optimised bytecode/x86 assembly } Should be fixed now in jruby-master. btw, one reason you might not have been able to reproduce on a cut-down codeset is because of the JIT threshold specifying -Xffi.compile.threshold=1 should make all FFI functions JIT on first use.
        Hide
        Chuck Remes added a comment -

        Wayne,

        a few comments.

        1. I did run this test with -Xcompile.mode=OFF and it crashed there too but with a different backtrace (though it ended up at the same Ruby code). Doesn't that disable the JIT which would have avoided the bug you just fixed?

        2. Since I posted this JIRA, I did get a crash on Windows in a similar place. Here is the hs_err*.log output: https://gist.github.com/1497411

        3. I updated to master on osx and your fix has repaired the issue. I am unable to build a working jruby from my git clone with 'ant dist' so that I can run this on Windows too; the build appears broken (but I don't think it's from your change). As soon as that build recipe is working again I'll try this on Windows.

        Show
        Chuck Remes added a comment - Wayne, a few comments. 1. I did run this test with -Xcompile.mode=OFF and it crashed there too but with a different backtrace (though it ended up at the same Ruby code). Doesn't that disable the JIT which would have avoided the bug you just fixed? 2. Since I posted this JIRA, I did get a crash on Windows in a similar place. Here is the hs_err*.log output: https://gist.github.com/1497411 3. I updated to master on osx and your fix has repaired the issue. I am unable to build a working jruby from my git clone with 'ant dist' so that I can run this on Windows too; the build appears broken (but I don't think it's from your change). As soon as that build recipe is working again I'll try this on Windows.
        Hide
        Wayne Meissner added a comment -

        Hi Chuck, -Xcompile.mode=OFF works now (i.e. disables FFI stub compilation), so you should be able to reproduce the windows crash on MacOS, assuming it isn't windows specific.

        Show
        Wayne Meissner added a comment - Hi Chuck, -Xcompile.mode=OFF works now (i.e. disables FFI stub compilation), so you should be able to reproduce the windows crash on MacOS, assuming it isn't windows specific.
        Hide
        Charles Oliver Nutter added a comment -

        Any update on this, Chuck? Perhaps holidays have kept you away...

        Show
        Charles Oliver Nutter added a comment - Any update on this, Chuck? Perhaps holidays have kept you away...
        Hide
        Chuck Remes added a comment -

        Wayne's fixes have resolved the issue. I can no longer reproduce the problem.

        Thanks for the quick turn around.

        Show
        Chuck Remes added a comment - Wayne's fixes have resolved the issue. I can no longer reproduce the problem. Thanks for the quick turn around.

          People

          • Assignee:
            Unassigned
            Reporter:
            Chuck Remes
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: