This is perhaps a bit obscure, but was still biting me when trying to debug an unrelated reference cycle.
In the process of debugging I set gc.disable() so that I can ensure that I can find the (otherwise collectable) reference cycle before it's collected.
However, when running objgraph.by_type, it seems that a reference cycle can be created between the stack frame for by_type and itself by way of the objects list. Normally this would be cleaned up on the next garbage collector run, but since I'm leaving automatic garbage collection disabled it sticks around. Then when I run gc.get_referrers on one of the objects returned by by_type, I get back the huge objects list as one of its referrers since it's still being tracked.
Manually deleting the objects list at the end of by_type ensures that any reference cycles involving it are broken and can be cleaned up before any further inspection is performed on an object's referrers.
This is perhaps a bit obscure, but was still biting me when trying to debug an unrelated reference cycle. In the process of debugging I set
gc.disable()
so that I can ensure that I can find the (otherwise collectable) reference cycle before it's collected.However, when running
objgraph.by_type
, it seems that a reference cycle can be created between the stack frame forby_type
and itself by way of theobjects
list. Normally this would be cleaned up on the next garbage collector run, but since I'm leaving automatic garbage collection disabled it sticks around. Then when I rungc.get_referrers
on one of the objects returned byby_type
, I get back the hugeobjects
list as one of its referrers since it's still being tracked.Manually deleting the
objects
list at the end ofby_type
ensures that any reference cycles involving it are broken and can be cleaned up before any further inspection is performed on an object's referrers.