Segmentation fault on ruby installed with rbenv - ruby-on-rails

Question

I use ruby 1.9.3 in a rails application. I successfully installed ruby using rbenv and gcc 4.2 on OSX Yosemite and could install dependencies with bundler.
When I try to setup the database I get the following error:
bundle exec rake db:setup
foo already exists
foo_test already exists
ruby(31773,0x7fff79ac7300) malloc: *** error for object 0x7fe00a8c0dc8: incorrect checksum for freed object - object was probably modified after being freed.
*** set a breakpoint in malloc_error_break to debug
[1] 31773 abort bundle exec rake db:setup
After the first time I get a different error message:
$ bundle exec rake db:setup
-- create_table("foo", {:force=>true})
-> 0.0241s
...
-- create_table("bar", {:force=>true})
-> 0.0241s
/Users/jedi/code/foo/.bundle/ruby/1.9.1/gems/activerecord-3.2.18/lib/active_record/migration.rb:601: [BUG] Segmentation fault
ruby 1.9.3p484 (2013-11-22 revision 43786) [x86_64-darwin14.3.0]
-- Control frame information -----------------------------------------------
c:0062 p:0012 s:0220 b:0220 l:000219 d:000219 METHOD /Users/jedi/code/foo/.bundle/ruby/1.9.1/gems/activerecord-3.2.18/lib/active_record/migration.rb:601
c:0061 p:0071 s:0216 b:0214 l:000195 d:000213 BLOCK /Users/jedi/code/foo/.bundle/ruby/1.9.1/gems/activerecord-3.2.18/lib/active_record/migration.rb:461
c:0060 p:0005 s:0212 b:0212 l:000201 d:000211 BLOCK /Users/jedi/code/foo/.bundle/ruby/1.9.1/gems/activerecord-3.2.18/lib/active_record/migration.rb:438
...
-- Ruby level backtrace information ----------------------------------------
/Users/jedi/code/foo/.bundle/ruby/1.9.1/bin/rake:23:in `<main>'
/Users/jedi/code/foo/.bundle/ruby/1.9.1/bin/rake:23:in `load'
...
[NOTE]
You may have encountered a bug in the Ruby interpreter or extension libraries.
Bug reports are welcome.
For details: http://www.ruby-lang.org/bugreport.html
I tried updating to ruby 2.0.0 and compiling ruby using clang, but always got the same. Any ideas?

Answer 1

This was caused by an incorrect version of zeromq being installed on the computer. We were using a gem that targets zeromq 3 but had version 4 installed.
I arrived to this conclusion after some binary search removing and adding dependencies from the Gemfile. Downgrading zeromq did the job.
To me it's still a mistery why the error report is so misleading, but problem solved.