I recently had to write and deploy a custom Rails app for a customer. When it was time for me to install the dedicated server, I looked for which Ruby version to install. I naturally went for the latest stable version of Ruby: 1.8.5. Unfortunalety I quickly ran through serious trouble with this version and Rails.
Mongrel for instance. I didn’t notice on their web site that asking for 1.8.4 was an absolute requirement. Just after a few hours running the web site in production, Mongrel just crashed and segfault! Wow, last time I saw a segfault was years ago. I had to fallback quickly to Webrick on the production server so I could downgrade Ruby to 1.8.4 as quickly as possible.
The stack trace shown me that a call to Thread.new in Mongrel’s code caused the segfault. Mongrel is using native code but the crash didn’t seem to have occured in that part. So if it’s into the Ruby VM code, that’s more annoying.
I read recent posts talking about issues with current implementation of Ruby. People know that the current VM is complex and difficult to hack. Apparently alternative implementations over Java/.NET and native implementation are on going. That’s a very hot topic and I hope something will emerge quickly.
I’ve been working with Java for 5 years and it’s stability is awesome. Crashes are rare and memory management works great. I hope I could say that to Ruby. We all know that’s not easy to sell a new technology in the enterprise world and that only one crash could easily let people think that’s not mature and ruin all your efforts.
For the moment, I would strongly advise to stick with Ruby 1.8.4 until further investigations are done. If somebody know anything about the issue, please let me know.
UPDATE (Feb 26th, 2007): The problem is now fixed! I finally found out what was breaking all my Ruby installation: GCC 4.0, preinstalled on Ubuntu 6.06. I recompiled Ruby and all gems with GCC 3.3 and now everything works perflectly: no more crash and no more memory leaks. It’s actually weird how many things GCC 4.0 breaks… I’m happy the story is over.



Add New Comment
Viewing 7 Comments
Thanks. Your comment is awaiting approval by a moderator.
Do you already have an account? Log in and claim this comment.
Do you already have an account? Log in and claim this comment.
Do you already have an account? Log in and claim this comment.
sudo gem install fastthread
Current version is 0.6.1 i believe
Do you already have an account? Log in and claim this comment.
Do you already have an account? Log in and claim this comment.
Thanks a lot for your help, I'll give it a try as soon as possible. If it actually fix the issue, I'm just wondering why this is not part of Ruby core or a mandatory dependency with Mongrel's gem.
By the way, do you know if Ruby has to be compiled with pthread support (thing that I've done) because it's not enabled by default.
Concerning the log file, I'm not rotating it at the moment...
Do you already have an account? Log in and claim this comment.
That's interesting that you are seeing this issue and are not rotating logs. Perhaps you should email the Mongrel mailing list and Zed will chime in.
Do you already have an account? Log in and claim this comment.
That's what I though concerning the installation procedure... Generally default settings are just fine.
I followed your advices and I managed to get more stability but I had to downgrade lots of software...
I'm now running with Ruby 1.8.4 + fastthread + Mongrel 0.3.13.3. I had the issue with Mongrel 0.3.13.4 and 1.0.
Actually, the configuration I use is also the choice of one my hosting provider (http://a2hosting.com) where I also run some Rails apps...
I'll try the Mongrel mailing list as you suggested.
Thanks for your help.
Do you already have an account? Log in and claim this comment.
I found some introspection code that dumps objects state but it's not easy to find out.
I you have suggestions.
Add New Comment
Trackbacks