*** set a breakpoint in malloc_error_break to debug #78

millisami opened this Issue Jan 24, 2011 · 12 comments

5 participants


Couple of days ago, it was working and the following error pops up minimal times.
But today, this is being generated and I'd restart spork again and again coz every rspec test while run breaks this.
Not sure whether its spork issue or not.
My setup is, Rails(3.0.0), Mongoid beta 19, rspec 2.4.0, Spork(0.8.4)

./bin/spork rspec
Using RSpec
Loading Spork.prefork block...
Spork is ready and listening on 8989!
ruby(5389,0x108981000) malloc: *** error for object 0x107ef91a0: incorrect checksum for freed object - object was probably modified after being freed.
*** set a breakpoint in malloc_error_break to debug

Well I upgraded to spork-0.9.0.rc2 and its much better. Doesn't crash often.
But still I get couple.
Hasn't anyone had this sort of problem?

sporkrb member

I haven't seen this before... your using ruby-debug?


Yes, I'm using ruby-debug19 on ruby 1.9.2

sporkrb member

Ok.... you're setting a breakpoint?


No breakpoints. Just the regular rails/rspec code.


Wondering if any progress was made with this? I'm getting the same error.

I'm running rails 3.0.9, ruby 1.9.2, spork 0.9.0.rc9, osx lion.

This is the kind of output I'm seeing in the spork terminal.

Spork is ready and listening on 8989!
Running tests with args ["--color", "--format", "doc", "spec/controllers/users/user_clinical_trials_controller_spec.rb"]...
ruby(22457,0x104ab2000) malloc: *** error for object 0x7fd5818864d0: incorrect checksum for freed object - object was probably modified after being freed.
*** set a breakpoint in malloc_error_break to debug

As a side note, I'm actually trying to do an upgrade on a code base from ree 1.8.7. The specs seem to run fine in the normal process but crash with the above message on almost every run of particular specs when using spork. There doesn't, however, seem to be a consistent point where this happens, it's a bit random. Most of the time it just exits the test run with no output in the client terminal, but as noted the above is displayed in the server terminal. Occasional, the entire spork process with exit, below is some output I took from one of the times this happened.

-- control frame ----------
c:0012 p:---- s:0046 b:0046 l:000045 d:000045 CFUNC  :raise
c:0011 p:0083 s:0042 b:0042 l:001820 d:001820 METHOD /Users/blake/.rvm/gems/ruby-1.9.2-p290/gems/spork-0.9.0.rc9/lib/spork/forker.rb:50
c:0010 p:0055 s:0038 b:0038 l:001610 d:001610 METHOD /Users/blake/.rvm/gems/ruby-1.9.2-p290/gems/spork-0.9.0.rc9/lib/spork/run_strategy/forking.rb:17
c:0009 p:0048 s:0032 b:0032 l:000031 d:000031 METHOD /Users/blake/.rvm/gems/ruby-1.9.2-p290/gems/spork-0.9.0.rc9/lib/spork/server.rb:48
c:0008 p:0098 s:0025 b:0025 l:000024 d:000024 METHOD /Users/blake/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/1.9.1/drb/drb.rb:1558
c:0007 p:0146 s:0021 b:0021 l:000020 d:000020 METHOD /Users/blake/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/1.9.1/drb/drb.rb:1518
c:0006 p:0042 s:0017 b:0017 l:0003c8 d:000016 BLOCK  /Users/blake/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/1.9.1/drb/drb.rb:1592
c:0005 p:---- s:0012 b:0012 l:000011 d:000011 FINISH
c:0004 p:---- s:0010 b:0010 l:000009 d:000009 CFUNC  :loop
c:0003 p:0068 s:0007 b:0007 l:0003c8 d:000006 BLOCK  /Users/blake/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/1.9.1/drb/drb.rb:1588
c:0002 p:---- s:0004 b:0004 l:000003 d:000003 FINISH
c:0001 p:---- s:0002 b:0002 l:000001 d:000001 TOP
-- Ruby level backtrace information ----------------------------------------
/Users/blake/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/1.9.1/drb/drb.rb:1588:in `block in main_loop'
/Users/blake/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/1.9.1/drb/drb.rb:1588:in `loop'
/Users/blake/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/1.9.1/drb/drb.rb:1592:in `block (2 levels) in main_loop'
/Users/blake/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/1.9.1/drb/drb.rb:1518:in `perform'
/Users/blake/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/1.9.1/drb/drb.rb:1558:in `perform_without_block'
/Users/blake/.rvm/gems/ruby-1.9.2-p290/gems/spork-0.9.0.rc9/lib/spork/server.rb:48:in `run'
/Users/blake/.rvm/gems/ruby-1.9.2-p290/gems/spork-0.9.0.rc9/lib/spork/run_strategy/forking.rb:17:in `run'
/Users/blake/.rvm/gems/ruby-1.9.2-p290/gems/spork-0.9.0.rc9/lib/spork/forker.rb:50:in `result'
/Users/blake/.rvm/gems/ruby-1.9.2-p290/gems/spork-0.9.0.rc9/lib/spork/forker.rb:50:in `raise'

-- C level backtrace information -------------------------------------------
0   libruby.1.9.1.dylib                 0x0000000109a695c2 rb_vm_bugreport + 210
1   libruby.1.9.1.dylib                 0x0000000109922e64 report_bug + 372
2   libruby.1.9.1.dylib                 0x0000000109923028 rb_bug + 200
3   libruby.1.9.1.dylib                 0x000000010992366e rb_bug_errno + 1598
4   libruby.1.9.1.dylib                 0x0000000109a6effa thread_raise_m + 186
5   libruby.1.9.1.dylib                 0x0000000109a64ad3 vm_call_method + 931
6   libruby.1.9.1.dylib                 0x0000000109a4fe63 vm_exec_core + 4739
7   libruby.1.9.1.dylib                 0x0000000109a58923 vm_exec + 1507
8   libruby.1.9.1.dylib                 0x0000000109a66e61 loop_i + 561
9   libruby.1.9.1.dylib                 0x0000000109928017 rb_rescue2 + 519
10  libruby.1.9.1.dylib                 0x0000000109a4bb26 rb_f_loop + 54
11  libruby.1.9.1.dylib                 0x0000000109a64ad3 vm_call_method + 931
12  libruby.1.9.1.dylib                 0x0000000109a4fe63 vm_exec_core + 4739
13  libruby.1.9.1.dylib                 0x0000000109a58923 vm_exec + 1507
14  libruby.1.9.1.dylib                 0x0000000109a59c9d rb_vm_invoke_proc + 877
15  libruby.1.9.1.dylib                 0x0000000109a71109 thread_start_func_2 + 1673
16  libruby.1.9.1.dylib                 0x0000000109a712cd thread_start_func_1 + 29
17  libsystem_c.dylib                   0x00007fff8d24d8bf _pthread_start + 335
18  libsystem_c.dylib                   0x00007fff8d250b75 thread_start + 13

Seeing this also on OSX Lion (10.7.2) with spork 1.0.0rc2, spork-rails 3.2.0 and rails 3.2.1

Additional info that might be related/useful:

  • It happens for my rspec, but not for cucumber.
  • It seems to happen only on the first run.
    • After that I get rspec errors related to ActiveRecord associations not being defined (undefined method 'tournament=', Could not find the source association(s), etc...).
  • Without spork, I can just type rspec and it will execute everything under my /specs directory, but when using sport I need to specify it explicitly: rspec --drb specs

Are there any pointers on where I could start looking?

sporkrb member

The stack trace points to this:


Looking at this code... sigh... I see problems here. There's a race condition between the Process.wait and the raise... definite problems. I'll refactor and clean this up, push a new version.

sporkrb member

After thinking about it further, while the code is more complex than it need be, I don't see a condition where a signal would be raised in a dead thread under normal circumstances, which is what I suspect may be causing the ruby segault issues.

I've pushed a refactoring of the method to the master branch. You might copy the master version of forker.rb to your installed gem's version and see if it fixes the issue.



Didn't fix it for me, sorry. Thanks for looking at it over the weekend, though.


I've tracked this to a spec using libxml-ruby

If I skip that test when using spork, everything is fine:

unless defined? Spork && Spork.using_spork?
  describe "a component using libxml-ruby" do

(This is without the changes to forker.rb linked above)

My libxml-ruby is built against:

$ otool -L /Users/amuino/.rvm/gems/ruby-1.9.3-p0\@projectx/gems/libxml-ruby-2.2.2/ext/libxml/libxml_ruby.bundle 
    /Users/amuino/.rvm/rubies/ruby-1.9.3-p0/lib/libruby.1.9.1.dylib (compatibility version 1.9.1, current version 1.9.1)
    /usr/lib/libxml2.2.dylib (compatibility version 10.0.0, current version 10.3.0)
    /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.5)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0)
    /usr/lib/libicucore.A.dylib (compatibility version 1.0.0, current version 46.1.0)
    /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
    /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)

I'm seeing the same issue, also with a spec using libxml-ruby. Is there any workaround or fix for this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment