How Do I Debug This?

[James Edward Gray II]

I'm getting an error in a test suite for an FFI project:

=
..........................................................................=
..................................................................ruby(175=
6) 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

 

[Jeremy Hinegardner]

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.

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

 

[Roger Pack]

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

 

[James Edward Gray II]

..........................................................................=
..................................................................ruby(175=
6) malloc: *** error for object 0x101c39310: pointer being freed was not =
allocated

=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

 

[Roger Pack]

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

http://railsquestions.blogspot.com/2009/01/compiling-ruby-with-debug-symbols-in.html

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