Details

    • Type: Bug Bug
    • Status: Resolved Resolved
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: JRuby 1.6.4
    • Fix Version/s: JRuby-OSSL 0.7.6
    • Component/s: C Extensions
    • Labels:
      None
    • Environment:
      Mac OS Lion, jruby 1.6.3 (ruby-1.8.7-p330) (2011-10-26 d9009b7) (Java HotSpot(TM) 64-Bit Server VM 1.6.0_26) [darwin-x86_64-java]
    • Number of attachments :
      0

      Description

      Error is usually along the lines of:

      java(61909,0x10d6e6000) malloc: *** error for object 0x7ff14a8307c0: pointer being freed was not allocated
      *** set a breakpoint in malloc_error_break to debug
      

      JRuby 1.6.3 didn't have this issue, JRuby 1.6.4 and 1.6.5 do.

      Git bisect (using `ant clean cext` shows the bad commit as:

      d9009b75eb0dc63b17c3583549f9042135737224 is the first bad commit
      commit d9009b75eb0dc63b17c3583549f9042135737224
      Author: Wayne Meissner <wmeissner@gmail.com>
      Date:   Mon Aug 15 21:14:51 2011 +1000
      
          Improve cext ruby object -> native handle GC correctness
      
      :040000 040000 cf2e090681f2ab84eded1eda90e5daec26ba0fed 13d9c3697b91e2ed4a7303bf7ab84e9670ab0ef0 M	cext
      :040000 040000 f5900d637bdbd8cb82cc1f40dfc8afe2841108fd e4f2e5f9b43b5bd4d8174ff1005f600df6ba7028 M	src
      

        Issue Links

          Activity

          Hide
          Erik Hatcher added a comment -

          Help! I'm encountering this problem too using Rails 3.1.1 app experiences this on Mac OS 10.6.8 and JRuby 1.6.5:

          $ ruby -v # via "rvm install jruby"
          jruby 1.6.5 (ruby-1.8.7-p330) (2011-10-25 9dcd388) (Java HotSpot(TM) 64-Bit Server VM 1.6.0_26) [darwin-x86_64-java]
          

          "rails server" starts up fine, but the first request attempt to it dies with this malloc error.

          Is no one else experiencing this? Seems like this would be a common pain point if it's not just me.

          Show
          Erik Hatcher added a comment - Help! I'm encountering this problem too using Rails 3.1.1 app experiences this on Mac OS 10.6.8 and JRuby 1.6.5: $ ruby -v # via "rvm install jruby" jruby 1.6.5 (ruby-1.8.7-p330) (2011-10-25 9dcd388) (Java HotSpot(TM) 64-Bit Server VM 1.6.0_26) [darwin-x86_64-java] "rails server" starts up fine, but the first request attempt to it dies with this malloc error. Is no one else experiencing this? Seems like this would be a common pain point if it's not just me .
          Hide
          Hiro Asari added a comment -

          Don't use Thin. There are plenty of other viable application servers available.

          Show
          Hiro Asari added a comment - Don't use Thin. There are plenty of other viable application servers available.
          Hide
          Mat Schaffer added a comment -

          I'm running a rails 3.1.1 app on jruby with trinidad. Works quite nicely. Just make sure to use the -t option if you need inline debugging. Otherwise the output comes from up to 5 threads and can be a bit confusing.

          Show
          Mat Schaffer added a comment - I'm running a rails 3.1.1 app on jruby with trinidad. Works quite nicely. Just make sure to use the -t option if you need inline debugging. Otherwise the output comes from up to 5 threads and can be a bit confusing.
          Hide
          Hiro Asari added a comment -

          Wayne,

          Can you take a look?

          Show
          Hiro Asari added a comment - Wayne, Can you take a look?
          Hide
          Stina added a comment -

          I got a similar error when I forgot the 'jruby -S' prefix before the rails commands. I started over and the server is working now.

          FYI, I was getting this error at the first request:
          java(69715,0x10fd44000) malloc: *** error for object 0x101725040: pointer being freed was not allocated

          Show
          Stina added a comment - I got a similar error when I forgot the 'jruby -S' prefix before the rails commands. I started over and the server is working now. FYI, I was getting this error at the first request: java(69715,0x10fd44000) malloc: *** error for object 0x101725040: pointer being freed was not allocated
          Hide
          Hiro Asari added a comment -

          Please try it without RVM. If it works without RVM, then it is most likely a bad interaction with RVM's black magic.

          Show
          Hiro Asari added a comment - Please try it without RVM. If it works without RVM, then it is most likely a bad interaction with RVM's black magic.
          Hide
          Mat Schaffer added a comment -

          @Stina, do you have any other gems with C extensions in your Gemfile? It's possible that this problem extends beyond thin.

          @Hiro, my original test was without rvm on a clone of master.

          Show
          Mat Schaffer added a comment - @Stina, do you have any other gems with C extensions in your Gemfile? It's possible that this problem extends beyond thin. @Hiro, my original test was without rvm on a clone of master.
          Hide
          Aaron Bedra added a comment - - edited

          I can verify having this issue as well. Reverting back to 1.6.3 fixes things for me. BTW, I am not trying to run thin or rails 3.1. This is rails 3.0.11. I am using RVM 1.10.0 though.

          Show
          Aaron Bedra added a comment - - edited I can verify having this issue as well. Reverting back to 1.6.3 fixes things for me. BTW, I am not trying to run thin or rails 3.1. This is rails 3.0.11. I am using RVM 1.10.0 though.
          Hide
          Scott Gonyea added a comment - - edited

          Oddly enough, I can reproduce this with a piece of code of mine. This issue seems to happen (in my case) when using autoload. Very very strange. If there's any interest, I can provide my code with steps to reproduce. I'm not sure if this is only a Mac/LLVM-GCC issue, or what.

          Requiring the file that was being autoloaded, and then calling into my code, prevents the following from happening:

          java(67870,0x114f20000) malloc: *** error for object 0x109635880: pointer being freed was not allocated

              • set a breakpoint in malloc_error_break to debug
                Abort trap: 6

          Edit: I spoke too soon. Argh.

          Show
          Scott Gonyea added a comment - - edited Oddly enough, I can reproduce this with a piece of code of mine. This issue seems to happen (in my case) when using autoload. Very very strange. If there's any interest, I can provide my code with steps to reproduce. I'm not sure if this is only a Mac/LLVM-GCC issue, or what. Requiring the file that was being autoloaded, and then calling into my code, prevents the following from happening: java(67870,0x114f20000) malloc: *** error for object 0x109635880: pointer being freed was not allocated set a breakpoint in malloc_error_break to debug Abort trap: 6 Edit: I spoke too soon. Argh.
          Hide
          Mat Schaffer added a comment -

          @Scott, do you have some code that triggers this by just running it? Such code could be a useful test case. I had to start a server and issue two requests to trigger it which made even just running `git bisect` quite tedious.

          Show
          Mat Schaffer added a comment - @Scott, do you have some code that triggers this by just running it? Such code could be a useful test case. I had to start a server and issue two requests to trigger it which made even just running `git bisect` quite tedious.
          Hide
          Ben Porterfield added a comment - - edited

          I'm also encountering this error with my fork of the puma server: https://github.com/bporterfield/puma

          jruby 1.6.5.1 (ruby-1.9.2-p136) (2011-12-27 1bf37c2) (Java HotSpot(TM) 64-Bit Server VM 1.6.0_29) [darwin-x86_64-java]

          Interestingly, I only see the error when using bundler and bundling the gem from github. If I use bundler to pull the gem from a local path, the error never occurs! There, I have compiled the java extension by hand.

          My first thought is that somehow, compilation of the extension is different? Is bundler + jruby using the C extension instead of the Java one? I'll try to narrow down the issue.

          Show
          Ben Porterfield added a comment - - edited I'm also encountering this error with my fork of the puma server: https://github.com/bporterfield/puma jruby 1.6.5.1 (ruby-1.9.2-p136) (2011-12-27 1bf37c2) (Java HotSpot(TM) 64-Bit Server VM 1.6.0_29) [darwin-x86_64-java] Interestingly, I only see the error when using bundler and bundling the gem from github. If I use bundler to pull the gem from a local path, the error never occurs! There, I have compiled the java extension by hand. My first thought is that somehow, compilation of the extension is different? Is bundler + jruby using the C extension instead of the Java one? I'll try to narrow down the issue.
          Hide
          Charles Oliver Nutter added a comment -

          If someone wants to help investigate this, here's the recipe: it worked fine in 1.6.3, and started failing in 1.6.4. There's a cext commit sometime between there that caused it.

          If someone's able to bisect this to a specific commit, I will be very grateful. 1.6.3 and 1.6.4 are tagged in github, both along the jruby-1_6 branch. Building JRuby + cext is just "ant cext" or "ant clean cext" to clean as well.

          Show
          Charles Oliver Nutter added a comment - If someone wants to help investigate this, here's the recipe: it worked fine in 1.6.3, and started failing in 1.6.4. There's a cext commit sometime between there that caused it. If someone's able to bisect this to a specific commit, I will be very grateful. 1.6.3 and 1.6.4 are tagged in github, both along the jruby-1_6 branch. Building JRuby + cext is just "ant cext" or "ant clean cext" to clean as well.
          Hide
          Mat Schaffer added a comment -

          That's what I did to determine d9009b75e above. Unfortunately I have no idea how this code works.

          The current catch is that the only way I've managed to get it to segfault is to start a server and make some requests to the running webapp. Sometimes it took two page loads. I'll see if I can build a git repo which demonstrates the problem. Maybe we can extract a more succinct test case from that.

          Show
          Mat Schaffer added a comment - That's what I did to determine d9009b75e above. Unfortunately I have no idea how this code works. The current catch is that the only way I've managed to get it to segfault is to start a server and make some requests to the running webapp. Sometimes it took two page loads. I'll see if I can build a git repo which demonstrates the problem. Maybe we can extract a more succinct test case from that.
          Hide
          Mat Schaffer added a comment -

          Here's a repository that should demonstrate the issue: https://github.com/matschaffer/jruby_6164

          Screencast is exporting now.

          Show
          Mat Schaffer added a comment - Here's a repository that should demonstrate the issue: https://github.com/matschaffer/jruby_6164 Screencast is exporting now.
          Hide
          Mat Schaffer added a comment -

          Screencast is at http://vimeo.com/36837708 and should be viewable within the hour.

          Show
          Mat Schaffer added a comment - Screencast is at http://vimeo.com/36837708 and should be viewable within the hour.
          Hide
          Charles Oliver Nutter added a comment -

          Wow, I totally missed that you narrowed it to a specific commit. Kudos.

          We'll look into it from there.

          Show
          Charles Oliver Nutter added a comment - Wow, I totally missed that you narrowed it to a specific commit. Kudos. We'll look into it from there.
          Hide
          Charles Oliver Nutter added a comment -

          Actually, if you can try 1.6.7, that help. There have been a set of cext fixes recently. I'm trying to come up with a small reproduction we can give to Wayne or Tim...

          Show
          Charles Oliver Nutter added a comment - Actually, if you can try 1.6.7, that help. There have been a set of cext fixes recently. I'm trying to come up with a small reproduction we can give to Wayne or Tim...
          Hide
          Charles Oliver Nutter added a comment -

          Mat: I'm trying your repo on jruby-1_6 branch now.

          Show
          Charles Oliver Nutter added a comment - Mat: I'm trying your repo on jruby-1_6 branch now.
          Hide
          Charles Oliver Nutter added a comment -

          CONFIRMED! Ok...so ignore all my complete obliviousness to bisecting, reproductions, and everything else on this bug. Looks good, Mat...I think if it can be fixed, we have what we need to diagnose it.

          Show
          Charles Oliver Nutter added a comment - CONFIRMED! Ok...so ignore all my complete obliviousness to bisecting, reproductions, and everything else on this bug. Looks good, Mat...I think if it can be fixed, we have what we need to diagnose it.
          Hide
          Mat Schaffer added a comment -

          Great! And thanks so much for JRuby, it's been an invaluable tool.

          Show
          Mat Schaffer added a comment - Great! And thanks so much for JRuby, it's been an invaluable tool.
          Hide
          Wayne Meissner added a comment -

          I think I fixed this in commit 204f5d669b2604a72957006990ee59e8a5e19ae8

          At least, running Mat's test case, no longer crashes. Should cherry-pick that back to 1.6.x once someone else confirms it as fixed.

          Show
          Wayne Meissner added a comment - I think I fixed this in commit 204f5d669b2604a72957006990ee59e8a5e19ae8 At least, running Mat's test case, no longer crashes. Should cherry-pick that back to 1.6.x once someone else confirms it as fixed.
          Hide
          Mat Schaffer added a comment -

          Just tested on 27b399053666545a which contains 204f5d669b2 and the server stayed running after 60s. I also tested against b97c22a (204f5d669b2^) which crashed after 5s. Looks like you got it. Well done, Wayne!

          Show
          Mat Schaffer added a comment - Just tested on 27b399053666545a which contains 204f5d669b2 and the server stayed running after 60s. I also tested against b97c22a (204f5d669b2^) which crashed after 5s. Looks like you got it. Well done, Wayne!
          Hide
          Charles Oliver Nutter added a comment -

          Cherry-picked to 1.6! Thanks everyone!

          commit 8905123edf98610511b3ce12dd5a4d22d813c3c7
          Author: Wayne Meissner <wmeissner@gmail.com>
          Date:   Thu Feb 16 13:02:12 2012 +1000
          
              Fix JRUBY-6164.  Problem was multiple cleaners on the same data object.
          
          Show
          Charles Oliver Nutter added a comment - Cherry-picked to 1.6! Thanks everyone! commit 8905123edf98610511b3ce12dd5a4d22d813c3c7 Author: Wayne Meissner <wmeissner@gmail.com> Date: Thu Feb 16 13:02:12 2012 +1000 Fix JRUBY-6164. Problem was multiple cleaners on the same data object.

            People

            • Assignee:
              Charles Oliver Nutter
              Reporter:
              Mat Schaffer
            • Votes:
              2 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: