bugs in `gc.get_referents()'

[Martin von Loewis]

Michael Hudson <mwh at python.net> writes:

> Wild, wild stab in the dark: try running gc.collect() first.

That shouldn't matter. Certainly, gc.get_referrers may return
referrers that the next collection would eliminate. However, if one
such object is found, it is added to the list that will be returned
from get_referrers, so it won't be collected as it is still referenced
from the result list.

Also, AFAICT, the only thing that could trigger a collection is the
allocation of the result list. However, that happens before the
generations are being traversed, so that could not cause problems,
either.

> I *doubt* threads are running during the call to gc.get_referrers.
> Could be wrong.

You are right. As every other C function, get_referrers holds the
interpreter lock. 

> > Also some of those threads are using native code which might be
> > failing to DECREF properly.
> 
> If that's the case, then you've got problems all your own, no?

That is my suspicion. get_referrers accesses every object that claims
to be a container, without attempting a garbage collection. Some
extension types may not expect that, but they would be broken already.

> > whether the code has been changed since 2.2b2,
> 
> Only the name changes, I think.

Correct.

> > if there is any sort of "starting point" for digging into it that
> > they recommend, etc.
> 
> $ less Modules/gcmodule.c
> 
> I think.

Investigating the objects that are incorrectly returned as referrers
are a good starting point, also. Set a breakpoint on the tp_traverse
of these types, and watch it being called. Find out why it returns
non-zero.

Regards,
Martin