From: Aman Gupta <rubytalk@...1.net>
Date: 2009-03-31T08:06:10+09:00
Subject: [ruby-core:23068] Re: [Bug #744] memory leak in callcc?

I've had no more issues since reverting mbari2. I'm able to reproduce
the segfault on my mac:

ruby(83833) malloc: *** error for object 0x152e6d4: Non-aligned
pointer being freed
*** set a breakpoint in malloc_error_break to debug
ruby(83833) malloc: *** error for object 0x152d154: Non-aligned
pointer being freed
*** set a breakpoint in malloc_error_break to debug
ruby(83891) malloc: *** error for object 0x152e6d4: Non-aligned
pointer being freed
*** set a breakpoint in malloc_error_break to debug
ruby(83891) malloc: *** error for object 0x152d154: Non-aligned
pointer being freed
*** set a breakpoint in malloc_error_break to debug

./gems/local/gems/god-0.7.8/bin/../lib/god/process.rb:183: [BUG] Bus Error
/opt/ruby-fiber/lib/ruby/1.8/net/http.rb:439: [BUG] Segmentation fault

Using gdb to breakpoint malloc_error_break shows:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000016
blk_copy_prev (block=0x15623b0) at eval.c:8549
8549		for (vars = tmp->dyna_vars; vars; vars = vars->next) {

(gdb) bt
#0  blk_copy_prev (block=0x15623b0) at eval.c:8549
#1  0x00020697 in proc_alloc (klass=1236720, proc=0) at eval.c:8773
#2  0x00022ea7 in rb_eval (self=6141440, n=<value temporarily
unavailable, due to optimizations>) at eval.c:3780
#3  0x00026480 in rb_call0 (klass=6141380, recv=6141440, id=5313,
oid=5313, argc=0, argv=0xbfff4268, body=0x5266d8, flags=<value
temporarily unavailable, due to optimizations>) at eval.c:6130
#4  0x000269dc in rb_call (klass=6141380, recv=6141440, mid=5313,
argc=2, argv=0xbfff4260, scope=0, self=18370740) at eval.c:6233
#5  0x00024002 in rb_eval (self=18370740, n=<value temporarily
unavailable, due to optimizations>) at eval.c:3517
#6  0x000253d6 in rb_eval (self=18370740, n=<value temporarily
unavailable, due to optimizations>) at eval.c:3242
#7  0x00024be4 in rb_eval (self=18370740, n=<value temporarily
unavailable, due to optimizations>) at eval.c:3328
#8  0x00026480 in rb_call0 (klass=6122780, recv=18370740, id=8457,
oid=8457, argc=0, argv=0x0, body=0x52b750, flags=<value temporarily
unavailable, due to optimizations>) at eval.c:6130
#9  0x000269dc in rb_call (klass=6122780, recv=18370740, mid=8457,
argc=0, argv=0x0, scope=0, self=18375120) at eval.c:6233
#10 0x00024002 in rb_eval (self=18375120, n=<value temporarily
unavailable, due to optimizations>) at eval.c:3517
#11 0x00023d15 in rb_eval (self=18375120, n=<value temporarily
unavailable, due to optimizations>) at eval.c:3702
#12 0x00026480 in rb_call0 (klass=5519380, recv=18375120, id=27009,
oid=27009, argc=0, argv=0xbfff5344, body=0x5474dc, flags=<value
temporarily unavailable, due to optimizations>) at eval.c:6130
#13 0x000269dc in rb_call (klass=5519380, recv=18375120, mid=27009,
argc=1, argv=0xbfff5340, scope=0, self=18374940) at eval.c:6233
#14 0x00024002 in rb_eval (self=18374940, n=<value temporarily
unavailable, due to optimizations>) at eval.c:3517
#15 0x0002296e in rb_eval (self=18374940, n=<value temporarily
unavailable, due to optimizations>) at eval.c:2966
#16 0x00026480 in rb_call0 (klass=5500380, recv=18374940, id=26953,
oid=26953, argc=0, argv=0x0, body=0x540b50, flags=<value temporarily
unavailable, due to optimizations>) at eval.c:6130
#17 0x000269dc in rb_call (klass=5500380, recv=18374940, mid=26953,
argc=0, argv=0x0, scope=0, self=18374940) at eval.c:6233
#18 0x00024002 in rb_eval (self=18374940, n=<value temporarily
unavailable, due to optimizations>) at eval.c:3517
#19 0x00024be4 in rb_eval (self=18374940, n=<value temporarily
unavailable, due to optimizations>) at eval.c:3328
#20 0x0002a8d1 in rb_yield_0 (val=<value temporarily unavailable, due
to optimizations>, self=18374940, klass=0, flags=0, avalue=0) at
eval.c:5116
#21 0x0002c85d in loop_i () at eval.c:5249
#22 0x0001aa53 in rb_rescue2 (b_proc=0x2c820 <loop_i>, data1=0,
r_proc=0, data2=0) at eval.c:5513
#23 0x0001ab57 in rb_f_loop () at eval.c:5274
#24 0x00025adf in rb_call0 (klass=1301660, recv=18374940, id=4121,
oid=4121, argc=-1073782088, argv=0x0, body=0x13bdc0, flags=<value
temporarily unavailable, due to optimizations>) at eval.c:5951
#25 0x000269dc in rb_call (klass=1301660, recv=18374940, mid=4121,
argc=0, argv=0x0, scope=1, self=18374940) at eval.c:6233
#26 0x00022ffd in rb_eval (self=<value temporarily unavailable, due to
optimizations>, n=<value temporarily unavailable, due to
optimizations>) at eval.c:3532
#27 0x000253d6 in rb_eval (self=18374940, n=<value temporarily
unavailable, due to optimizations>) at eval.c:3242
#28 0x0002a8d1 in rb_yield_0 (val=<value temporarily unavailable, due
to optimizations>, self=18374940, klass=0, flags=0, avalue=2) at
eval.c:5116
#29 0x0002d8cb in rb_thread_start_0 (fn=0x2abc0 <rb_thread_yield>,
arg=0x11860b8, th=0x875a00) at eval.c:12408
#30 0x00025adf in rb_call0 (klass=1284640, recv=18374860, id=2961,
oid=3221192596, argc=1093632, argv=0xbfff6ee8, body=0x23f17,
flags=<value temporarily unavailable, due to optimizations>) at
eval.c:5951
#31 0x01184934 in ?? ()

I will try to dig into the issue a bit more with valgrind, etc.

  Aman

On Thu, Mar 19, 2009 at 11:08 PM, Brent Roman <brent@mbari.org> wrote:
>
> Aman,
>
> It's quite possible that the double-frees are occurring both with and
> without the MBARI2 patch, but they are not causing segfaults unless MBARI2
> is applied. �You may want to try using valgrind or some similar tool to
> catch the double frees. (valgrind is really very good at this)
>
> A few days ago, I pushed a branch to my github repo with the MBARI patches
> applied to ruby_1_8 head. �These patches use the "thread anchors" backported
> (by Nobu, I believe) from 1.9 . �It seems to be a bit slower than my
> approach, but it may well be more robust. � The branch is called
> ruby_1_8-mbari:
>
> git://github.com/brentr/matzruby.git
>
> http://github.com/brentr/matzruby/commits/ruby_1_8-mbari/
>
> It is a dev version, but this snapshot did pass the bundled ruby test suite
> and all my tests as well.
> It would give you the benefits of the MBARI2 patch via the thread anchors.
>
> I'd really be must interested in finding out whether there are still
> double-frees happening. �Let me know what you find. �If the double-frees
> only happen with MBARI2 applied, I'll consider replacing MBARI2 with the
> thread anchors from 1.8.8-dev
>
> - brent
>
>
>
> Aman Gupta-6 wrote:
>>
>> I can confirm that removing mbari2 fixes the issue. I was able to get
>> a better stack trace, but am still unsure about the root cause and
>> unable to reproduce it consistently. It seems like a double free is
>> occurring for some reason and that eventually causes the segfault.
>>
>> *** glibc detected *** free(): invalid pointer: 0x0000000002312734 ***
>> *** glibc detected *** free(): invalid pointer: 0x0000000002312734 ***
>>
>> Core was generated by `ruby gems/local/gems/god-0.7.8/bin/god'.
>> Program terminated with signal 6, Aborted.
>> #0 �0x00007fc3d0cbb07b in raise () from /lib/libc.so.6
>> (gdb) bt
>> #0 �0x00007fc3d0cbb07b in raise () from /lib/libc.so.6
>> ...
>>
>> God uses a double-fork to spawn processes, and it looks like the
>> double free usually occurs when the first forked process (in
>> process.rb:215) dies. God also uses a C extension
>> (http://github.com/mojombo/god/blob/master/ext/god/netlink_handler.c)
>> which could be causing issues across the fork.
>>
>> � Aman
>>
>> On Tue, Mar 10, 2009 at 8:46 PM, Brent Roman <brent@mbari.org> wrote:
>>>
>>> Aman,
>>>
>>> When I merge the MBARI patches with 1.8 HEAD, I also plan to replace the
>>> stack optimization introduced in the MBARI2 patch with the (better)
>>> thread
>>> anchors already in HEAD (which, I think, were originally backported from
>>> 1.9). � This should happen in the next week or so. �In the meantime, you
>>> might want to try this patch against the current (MBARI 8B) patches on
>>> 1.8.6
>>> or 1.8.7:
>>>
>>> http://www.nabble.com/file/p22385077/rmMBARI2.patch
>>>
>>> It just disables the MBARI2 patch and leaves the rest intact.
>>> It would be very helpful to find out whether or not that alone eliminates
>>> God's segfaults.
>>>
>>> Will you give this a try?
>>> If it works, I'll do an 8C patch that to replace the stack splicing of
>>> MBARI2 with stack anchors on 1.8.7-p72 and perhaps 1.8.6-p287 as well.
>>>
>>> - brent
>>>
>>
>>
>
> --
> View this message in context: http://www.nabble.com/-ruby-core%3A19846---Bug--744--memory-leak-in-callcc--tp20447794p22614822.html
> Sent from the ruby-core mailing list archive at Nabble.com.
>
>
>