[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=3D0x15623b0) at eval.c:8549
8549		for (vars =3D tmp->dyna_vars; vars; vars =3D vars->next) {

(gdb) bt
#0  blk_copy_prev (block=3D0x15623b0) at eval.c:8549
#1  0x00020697 in proc_alloc (klass=3D1236720, proc=3D0) at eval.c:8773
#2  0x00022ea7 in rb_eval (self=3D6141440, n=3D<value temporarily
unavailable, due to optimizations>) at eval.c:3780
#3  0x00026480 in rb_call0 (klass=3D6141380, recv=3D6141440, id=3D5313,
oid=3D5313, argc=3D0, argv=3D0xbfff4268, body=3D0x5266d8, flags=3D<value
temporarily unavailable, due to optimizations>) at eval.c:6130
#4  0x000269dc in rb_call (klass=3D6141380, recv=3D6141440, mid=3D5313,
argc=3D2, argv=3D0xbfff4260, scope=3D0, self=3D18370740) at eval.c:6233
#5  0x00024002 in rb_eval (self=3D18370740, n=3D<value temporarily
unavailable, due to optimizations>) at eval.c:3517
#6  0x000253d6 in rb_eval (self=3D18370740, n=3D<value temporarily
unavailable, due to optimizations>) at eval.c:3242
#7  0x00024be4 in rb_eval (self=3D18370740, n=3D<value temporarily
unavailable, due to optimizations>) at eval.c:3328
#8  0x00026480 in rb_call0 (klass=3D6122780, recv=3D18370740, id=3D8457,
oid=3D8457, argc=3D0, argv=3D0x0, body=3D0x52b750, flags=3D<value temporari=
ly
unavailable, due to optimizations>) at eval.c:6130
#9  0x000269dc in rb_call (klass=3D6122780, recv=3D18370740, mid=3D8457,
argc=3D0, argv=3D0x0, scope=3D0, self=3D18375120) at eval.c:6233
#10 0x00024002 in rb_eval (self=3D18375120, n=3D<value temporarily
unavailable, due to optimizations>) at eval.c:3517
#11 0x00023d15 in rb_eval (self=3D18375120, n=3D<value temporarily
unavailable, due to optimizations>) at eval.c:3702
#12 0x00026480 in rb_call0 (klass=3D5519380, recv=3D18375120, id=3D27009,
oid=3D27009, argc=3D0, argv=3D0xbfff5344, body=3D0x5474dc, flags=3D<value
temporarily unavailable, due to optimizations>) at eval.c:6130
#13 0x000269dc in rb_call (klass=3D5519380, recv=3D18375120, mid=3D27009,
argc=3D1, argv=3D0xbfff5340, scope=3D0, self=3D18374940) at eval.c:6233
#14 0x00024002 in rb_eval (self=3D18374940, n=3D<value temporarily
unavailable, due to optimizations>) at eval.c:3517
#15 0x0002296e in rb_eval (self=3D18374940, n=3D<value temporarily
unavailable, due to optimizations>) at eval.c:2966
#16 0x00026480 in rb_call0 (klass=3D5500380, recv=3D18374940, id=3D26953,
oid=3D26953, argc=3D0, argv=3D0x0, body=3D0x540b50, flags=3D<value temporar=
ily
unavailable, due to optimizations>) at eval.c:6130
#17 0x000269dc in rb_call (klass=3D5500380, recv=3D18374940, mid=3D26953,
argc=3D0, argv=3D0x0, scope=3D0, self=3D18374940) at eval.c:6233
#18 0x00024002 in rb_eval (self=3D18374940, n=3D<value temporarily
unavailable, due to optimizations>) at eval.c:3517
#19 0x00024be4 in rb_eval (self=3D18374940, n=3D<value temporarily
unavailable, due to optimizations>) at eval.c:3328
#20 0x0002a8d1 in rb_yield_0 (val=3D<value temporarily unavailable, due
to optimizations>, self=3D18374940, klass=3D0, flags=3D0, avalue=3D0) at
eval.c:5116
#21 0x0002c85d in loop_i () at eval.c:5249
#22 0x0001aa53 in rb_rescue2 (b_proc=3D0x2c820 <loop_i>, data1=3D0,
r_proc=3D0, data2=3D0) at eval.c:5513
#23 0x0001ab57 in rb_f_loop () at eval.c:5274
#24 0x00025adf in rb_call0 (klass=3D1301660, recv=3D18374940, id=3D4121,
oid=3D4121, argc=3D-1073782088, argv=3D0x0, body=3D0x13bdc0, flags=3D<value
temporarily unavailable, due to optimizations>) at eval.c:5951
#25 0x000269dc in rb_call (klass=3D1301660, recv=3D18374940, mid=3D4121,
argc=3D0, argv=3D0x0, scope=3D1, self=3D18374940) at eval.c:6233
#26 0x00022ffd in rb_eval (self=3D<value temporarily unavailable, due to
optimizations>, n=3D<value temporarily unavailable, due to
optimizations>) at eval.c:3532
#27 0x000253d6 in rb_eval (self=3D18374940, n=3D<value temporarily
unavailable, due to optimizations>) at eval.c:3242
#28 0x0002a8d1 in rb_yield_0 (val=3D<value temporarily unavailable, due
to optimizations>, self=3D18374940, klass=3D0, flags=3D0, avalue=3D2) at
eval.c:5116
#29 0x0002d8cb in rb_thread_start_0 (fn=3D0x2abc0 <rb_thread_yield>,
arg=3D0x11860b8, th=3D0x875a00) at eval.c:12408
#30 0x00025adf in rb_call0 (klass=3D1284640, recv=3D18374860, id=3D2961,
oid=3D3221192596, argc=3D1093632, argv=3D0xbfff6ee8, body=3D0x23f17,
flags=3D<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 <[e-mail]> 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 MBARI=
2
> is applied. =A0You 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 patche=
s
> applied to ruby_1_8 head. =A0These patches use the "thread anchors" backp=
orted
> (by Nobu, I believe) from 1.9 . =A0It seems to be a bit slower than my
> approach, but it may well be more robust. =A0 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 sui=
te
> 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. =A0Let me know what you find. =A0If the double-fr=
ees
> 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 =A00x00007fc3d0cbb07b in raise () from /lib/libc.so.6
>> (gdb) bt
>> #0 =A00x00007fc3d0cbb07b 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.
>>
>> =A0 Aman
>>
>> On Tue, Mar 10, 2009 at 8:46 PM, Brent Roman <[e-mail]> wrote:
>>>
>>> Aman,
>>>
>>> When I merge the MBARI patches with 1.8 HEAD, I also plan to replace th=
e
>>> stack optimization introduced in the MBARI2 patch with the (better)
>>> thread
>>> anchors already in HEAD (which, I think, were originally backported fro=
m
>>> 1.9). =A0 This should happen in the next week or so. =A0In 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 eliminat=
es
>>> 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.
>
>
>