On Jan 5, 2010, at 5:21 PM, Jeremy Hinegardner wrote:

> On Wed, Jan 06, 2010 at 07:59:34AM +0900, James Edward Gray II wrote:
>> I'm getting an error in a test suite for an FFI project:
>>=20
>> =
..........................................................................=
..................................................................ruby(175=
6) malloc: *** error for object 0x101c39310: pointer being freed was not =
allocated
>> *** set a breakpoint in malloc_error_break to debug
>>=20
>> I assume I'm forgetting to free an allocated chunk of memory.  What's =
te best way to zero in on the issue?
>>=20
>> Is the breakpoint suggestion a gdb tip?  Is there anywhere I could go =
read about how to look into that?
>>=20
>> Thanks in advance for the advice.
>>=20
>> James Edward Gray II
>=20
> When I have something like this, I generally will compile a debug (-g)
> version of ruby and then run the spec/test via gdb to figure it out.  =
Do a stack
> trace in gdb and look where the free is being called and go from =
there.=20

OK, just so I understand though, I'm pretty sure I'm looking at a bug =
that's triggered during GC here.

I thought the "ruby malloc" was a sign that Ruby is freeing up memory =
before it allocates more.

Also, all of my tests work fine when run alone.  It's not until they are =
combined that the problem surfaces.  I assume it's the longer run =
triggering GC.

Is this sounding right?

If it's in GC, a stack trace won't tell me much, right?  I guess about =
the only helpful thing would be to know which object is being freed when =
the error occurs.  Can I get that via gdb?

I assume it almost has to be an FFI object.  I mean, Ruby wouldn't try =
to free some memory allocated by the library I'm talking to, right?  Are =
there FFI objects that try to free something as they are GCed?

I guess I should move this to the FFI mailing list if I'm remotely right =
about any of this.

> I'm guessing that this might be showing up in your new OklahomaMixer =
project

Yes, it is.

> and that this free might be happening in relation to a Tokyo Cabinet =
call :-).

So you think it could be GC kicking in while FFI is setting up a call =
into C?

> If that is the case, I'd also compile a debug version of TC for you to =
use
> with FFI, and you might need a debug version of FFI also.

Good tips all around.  Thank you.

James Edward Gray II