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:
>> 
>> ............................................................................................................................................ruby(1756) malloc: *** error for object 0x101c39310: pointer being freed was not allocated
>> *** set a breakpoint in malloc_error_break to debug
>> 
>> I assume I'm forgetting to free an allocated chunk of memory.  What's te best way to zero in on the issue?
>> 
>> Is the breakpoint suggestion a gdb tip?  Is there anywhere I could go read about how to look into that?
>> 
>> Thanks in advance for the advice.
>> 
>> James Edward Gray II
> 
> 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. 

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