Phusion white papers Phusion overview

Phusion Blog

Ruby Enterprise Edition 1.8.7-2011.03 released

By Hongli Lai on February 24th, 2011

Yes folks, another REE release within 2 weeks. We won’t bother you with updates again for a while now, I swear. 😉 But this update is worth it. The changes are as follows.

Fixed threading bugs
As mentioned in the release notes for REE 2011.01, MRI 1.8 has threading bugs that still aren’t resolved in 1.8.7-p334. REE 2011.01 contains a fix for this problem, but after running it for a while in production we’ve discovered that the fix may cause crashes.

It turned out that MRI’s 1.8 branch (the one that is to become MRI 1.8.8) has an updated fix that doesn’t crash, and it has had this fix for more than a year now, but it isn’t included in MRI 1.8.7. We’ve notified the Ruby core team about this and Shyouhei Urabe says he’ll backport it to the next MRI 1.8.7 release. In the mean time we’ve taken the liberty to backport it ourselves.

Users with heavily multi-threaded Ruby apps are strongly advised to upgrade to REE 2011.03. Without this fix threading is effectively useless on both the upstream MRI 1.8.7 releases as well as previous REE releases.

Fixed compilation problems and potential crashes on OS X when MacPorts are used

OS X has this interesting ecosystem in which a lot of users install software through MacPorts. MacPorts software is typically installed to /opt/local. This causes two problems.

The first one is that the compiler does not look in /opt/local by default. Some Ruby gems with native extensions rely on third-party libraries not shipped with OS X. If the user installs those dependencies with MacPorts then gems may not detect them automatically.

The other problem is that people end up with different versions of libraries that are also shipped with the OS. For example OS X comes with OpenSSL 0.9.8 while MacPorts installs OpenSSL 1.0.0 to /opt/local. This may cause crashes when some libraries try to use OpenSSL 0.9.8 and others try to use 1.0.0! For example the we’ve installed libcurl via MacPorts. libcurl depends on OpenSSL so MacPorts installs that as well. The Curb gem depends on libcurl, and its extconf.rb is smart enough to look in /opt/local for libcurl, so the Curb C extension ends up being compiled against MacPorts’s OpenSSL 1.0.0. In the mean time, the Ruby OpenSSL extension’s extconf.rb does not look in /opt/local, so it ends up being compiled against OpenSSL 0.9.8. The net/https library uses the Ruby OpenSSL extension. So if your app uses both Curb and net/https (which may happen indirectly, e.g. via ActiveResource) then Ruby may attempt to load both OpenSSL libraries. These two conflict with each other and may cause crashes. So if you’re an OS X user and you’ve seen mysterious segmentation fault crashes in net/http.rb, then this is probably the cause. Obviously the problem is not limited to only OpenSSL: any situation involving two different versions of the same library to be loaded will cause problems as well.

To fix all this we’ve now modified REE to always look in /opt/local when compiling things.

Download & upgrade

To install Ruby Enterprise Edition, please visit the download page. To upgrade from a previous version, simply install into the same prefix that you installed to last time. Please also refer to the documentation for upgrade instructions.

  • Cool, thanks for update.

  • Cool! – many update these days but thank you very much for keep up the fix.

    Is this release address issue with passenger? I tried both 3.0.2 and 2.2.15

    *** glibc detected *** Passenger ApplicationSpawner: /srv/www/apps/xxxxxx/current: munmap_chunk(): invalid pointer: 0x0000000000ccd400 ***
    ======= Backtrace: =========

  • @Jirapong: That looks like a system issue to me. But please report at the bug tracker. Include as much details as possible – OS name, version, CPU architecture, username that your app is supposed to run as, etc.

  • The last time 1.8.8 was brought up on the ruby-core mailing list the future of the 1.8 branch was undecided. I felt there was a strong lean towards not releasing a 1.8.8 as 1.9.2 was a better target. Has this changed but not been announced on the ruby-core mailing list?

  • Joni Orponen

    The way to fix the “MacPorts compile issue” is not to hardcode more and more obscure (non-FHS) paths into installation scripts, but to actually rely on the end user being able to manage their own self-set UNIX environment appropriately.

    In this case the appropriate instruction would be to direct users to set their environmental variables to point to where ever they decide to install their junk: in the case of MacPorts that happens to be /opt/local.

    I am also providing an example of my basic userspace overlay hierarchy setup:

    DYLD* is OS X specific.

    Paths are iterated through sequentially and the first hit per search is used: the user can easily set which parallel resource supersedes which under which conditions.

  • @Erik: I don’t know about the status of 1.8.8 but Urabe says he’ll backport the patch to 1.8.7.

  • Josh

    I can not get REE 1.8.7 (any release) to build in FreeBSD i386.

    REE 1.8.6 builds without any problems in FreeBSD i386.
    REE 1.8.7 builds without any problems in FreeBSD amd64.

    gcc -g -O2 -DRUBY_EXPORT -L. -rdynamic main.o libruby-static.a -L/opt/local/lib -Wl,-rpath,/local0/ruby-enterprise-1.8.7-2011.03/lib -L/local0/ruby-enterprise-1.8.7-2011.03/lib -ltcmalloc_minimal -lpthread -lrt -lcrypt -lm -o miniruby
    Illegal instruction (core dumped)
    *** Error code 132

    #0 0x0807418e in garbage_collect () at gc.c:2197
    #1 0x08074255 in rb_newobj () at gc.c:1000
    #2 0x0809316f in rb_node_newnode (type=NODE_LASGN, a0=11233, a1=0, a2=2) at parse.y:4592
    #3 0x08094ca2 in assignable (id=11233, val=0x0) at parse.y:4995
    #4 0x0809987c in ruby_yyparse () at parse.y:853
    #5 0x080a259f in yycompile (f=0x81e3d60 “./lib/fileutils.rb”, line=1) at parse.y:2692
    #6 0x080b846c in load_file (fname=0x81e3d60 “./lib/fileutils.rb”, script=0) at ruby.c:977
    #7 0x08069c1d in rb_load (fname=135986620, wrap=0) at eval.c:7194
    #8 0x0806a127 in rb_require_safe (fname=136009820, safe=0) at eval.c:7578
    #9 0x0805dad8 in rb_call0 (klass=136084640, recv=136079700, id=9769, oid=9769, argc=1, argv=0xbfbfe670, body=0x81b82dc, flags=0)
    at eval.c:6058
    #10 0x0805dd61 in rb_call (klass=136084640, recv=136079700, mid=9769, argc=1, argv=0xbfbfe670, scope=1, self=136079700)
    at eval.c:6308
    #11 0x08067756 in eval_fcall (self=136079700, node=0x81b5834) at eval.c:3396
    #12 0x0805c351 in rb_eval (self=136079700, node=0x81b580c) at eval.c:3858
    #13 0x0806b1b7 in ruby_exec_internal () at eval.c:1685
    #14 0x0806b1e6 in ruby_exec () at eval.c:1705
    #15 0x0806b211 in ruby_run () at eval.c:1715
    #16 0x08053c0f in main (argc=Cannot access memory at address 0x2f749c
    ) at main.c:48

  • Piyush Ranjan

    When are twitter GC changes getting into REE as a release ? 2011.04 ?

  • Pingback: OCTO talks ! » Quelques niouses (en) Ruby du mois de Mars()

  • Jonathan

    What’s the status of REE 1.9.x?

  • Pingback: Ruby 1.9.2 Segmentation Fault and OpenSSL()