malloc error trying to run rails 3.1 app on thin

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.

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

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.

Wayne,

Can you take a look?

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

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

@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.

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.

@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.

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.

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.

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.

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

Screencast is exporting now.

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

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

We'll look into it from there.

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...

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

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.

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

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.

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!

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.