Debugging garbage collection

ruby-talk
1

I have a Ruby program that seems to be leaking memory – in the sense
that objects which I think should be GCed aren’t getting GCed (even if
I call GC.start).
Something must be keeping references to these objects, but I can’t
figure out what.

Are there any tools to debug this problem? Some way to watch the GC in
operation, or to find references to a particular object (at runtime),
would be helpful.

Nathan

2

Nathan Weston wrote:

I have a Ruby program that seems to be leaking memory – in the sense
that objects which I think should be GCed aren’t getting GCed (even if
I call GC.start).
Something must be keeping references to these objects, but I can’t
figure out what.

Are there any tools to debug this problem? Some way to watch the GC in
operation, or to find references to a particular object (at runtime),
would be helpful.

I’m not aware of any such GC debugging tools.

I guess the obvious question (to me) is: What behavior makes you think
that objects aren’t getting collected?

Hal

3

I don’t know that I can help you figure out “what” has references, but why
not use ObjectSpace to see what’s alive at a particular point in time?

-austin

···

On Sun, 14 Sep 2003 07:41:38 +0900, Nathan Weston wrote:

I have a Ruby program that seems to be leaking memory – in the sense
that objects which I think should be GCed aren’t getting GCed (even if I
call GC.start).
Something must be keeping references to these objects, but I can’t figure
out what.

–
austin ziegler * austin@halostatue.ca * Toronto, ON, Canada
software designer * pragmatic programmer * 2003.09.13
* 22.56.45

4

Nathan Weston wrote:

I have a Ruby program that seems to be leaking memory – in the sense
that objects which I think should be GCed aren’t getting GCed (even if
I call GC.start).
Something must be keeping references to these objects, but I can’t
figure out what.

Are there any tools to debug this problem? Some way to watch the GC in
operation, or to find references to a particular object (at runtime),
would be helpful.

You can patch gc.c and variable.c to give some information. See

http://redshift.sourceforge.net/debugging-GC/

The patches there are for 1.6.7 and 1.7.2, unfortunately. I haven’t had
the need to update them.

What it gives you is a method you can call like:

GC.reachability_paths(obj)

and it will return an array of arrays, each of which is a path starting
from some root reference in the interpreter, and ending with an object
that contains a reference to obj. The root references can be ruby
objects or can be references on the stack or in globals, and those are
reported in descriptive strings, like

“frame : line ”
“Ruby global ”
“C global ”

5

Thanks, that sounds like just what I need. I’ll give it a try.

Nathan

Joel VanderWerf vjoel@PATH.Berkeley.EDU wrote in message news:3F64D69F.4070500@path.berkeley.edu…

···

Nathan Weston wrote:

I have a Ruby program that seems to be leaking memory – in the sense
that objects which I think should be GCed aren’t getting GCed (even if
I call GC.start).
Something must be keeping references to these objects, but I can’t
figure out what.

Are there any tools to debug this problem? Some way to watch the GC in
operation, or to find references to a particular object (at runtime),
would be helpful.

You can patch gc.c and variable.c to give some information. See

http://redshift.sourceforge.net/debugging-GC/

The patches there are for 1.6.7 and 1.7.2, unfortunately. I haven’t had
the need to update them.

What it gives you is a method you can call like:

GC.reachability_paths(obj)

and it will return an array of arrays, each of which is a path starting
from some root reference in the interpreter, and ending with an object
that contains a reference to obj. The root references can be ruby
objects or can be references on the stack or in globals, and those are
reported in descriptive strings, like

“frame : line ”
“Ruby global ”
“C global ”