Home Original page

gc.get_referrers trouble

Tim Peters tim.peters at gmail.com
Tue Sep 7 14:22:30 EDT 2004 
[Diez B. Roggisch]
> I'm in the process of debugging a mem-leaking app. A recent thread here on
> c.l.py mentioned the use of the gc module, so I gave it a try.
>
> However, using get_referrers() yields in literally thousands of objects for
> even the tiniest example like this:
>
> import gc
> a = [1]
> print  gc.get_referrers(1)
>
> Running that from bash gives me this:
>
> # python /tmp/test.py | wc
>     23    7196   67165

That just shows the number of lines (etc) of output, not how many
objects refer to 1.  len(gc.get_referrers(1)) would tell you how many
container objects refer to 1.  Little integers happen to be shared in
CPython, so there are likely to be referrers you don't know about.  I
expect there are several dozen objects total that refer to 1, but not
more than that.  Pick a larger number to match your "intuition"
better:

>>> len(gc.get_referrers(82938732))
1
>>>

> Now I'm confused - how do I interpret the results of get_referrers()
> correctly?

Start by not printing it as a string <wink>.  It's a list of container
objects.  The string representation of any one of those objects can
arbitrarily large.

A better start would be to download one of the test.py scripts for
Zope, and use a debug build.  There's a TrackRefs class defined in
test.py that displays deltas in object counts (by type) across calls
to its update() method.  Typical is to use that to find out which
kinds of objects are growing at an unreasonable rate, then fiddle the
guts of the TrackRefs class (via calls to things like gc.get_referrers
-- depends on where the evidence leads you) to zero in on a cause.
More information about the Python-list mailing list