How to check what is holding reference to object

[Chris Rebert]

On Tue, Apr 27, 2010 at 2:58 PM, Chris Rebert <clp2 at rebertia.com> wrote:
> On Tue, Apr 27, 2010 at 2:42 PM, Michal M <mich.mierzwa at googlemail.com> wrote:
>> On 27 Kwi, 23:21, Duncan Booth <duncan.bo... at invalid.invalid> wrote:
>>> Michal M <mich.mier... at googlemail.com> wrote:
>>> > I've just found out that one of objects is not destroyed when it
>>> > should be. This means that something was holding reference to this
>>> > object or part of it (i.e. method). Is there any way to check what
>>> > holds that reference? I am unable to do that just looking to the code
>>> > or debugging it because it is pretty complicated, but I am able to
>>> > invoke this situation again.
>>>
>>> See if this code helps:
>>>
>>> http://groups.google.com/group/comp.lang.python/browse_thread/thread/...
>>>
>>> It's pretty old so it may need some adjustment, but I wrote it
>>> to figure out exactly that sort of problem.
>>
>> Thanks you for answers.
>> I tried to use gc.get_referrers(self) in point in code when according
>> to me object should be destroyed earlier but I did not see anything
>> interesting. Then just realised that gc will not destroy object even
>> when itself holds reference to his own method.
>>
>> For example
>>
>> class A(object):
>>  def a(self):
>>    pass
>>  def b(self):
>>    self.method = self.a
>>  def __del__(self):
>>    print "A object deleted"
>>
>>>> a = A()
>>>> del a
>> A object delted
>>>> a = A()
>>>> a.b()
>>>> del a
>> ... nothing ...
>>
>> I thought gc would discover such circle loops but apparently it did
>> not.
>
> No, it does, you just didn't give it long enough; for performance
> reasons, cyclical GC is only done every so often:

Addendum:
Also, defining __del__ in your example was likely problematic:
See http://docs.python.org/library/gc.html#gc.garbage

- Chris