How Do I Debug This?

Ruby
1

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 G. II

2

On Wed, Jan 06, 2010 at 07:59:34AM +0900, James Edward G. II wrote:

James Edward G. 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.

I’m guessing that this might be showing up in your new OklahomaMixer
project
and that this free might be happening in relation to a Tokyo Cabinet
call :-).

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.

enjoy,

-jeremy

3

On Jan 5, 2010, at 5:21 PM, Jeremy H. wrote:

Thanks in advance for the advice.

James Edward G. 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 G. II

4

Jeremy H. wrote:

On Wed, Jan 06, 2010 at 07:59:34AM +0900, James Edward G. II wrote:

James Edward G. 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.

Like Jeremy said, you could run it in gdb by re-compiling your version
of ruby with debug symbols

then just run it in gdb and break on malloc_error_break
valgrind might be quite useful, too [and might not require a recompile].
GL.
-r

5

I assume I’m forgetting to free an allocated chunk of memory. What’s te
best way to zero in on the issue?

Running ruby under valgrind might help.
-r