gc.DEBUG_LEAK and gc.garbage

["Martin v. Löwis"]

Cesar wrote:
> I have set the DEBUG_LEAK flag with the GC and in the program cycle
> printed the length of the garbage list. Is this enough to determine if
> there is a leak in the python code? (the value rises). 

Well, define "a leak". It could mean a number of things:

- an object that is not used anymore, but still referenced
  from a "live" object.
  This will not be released until the reference from the live
  object is broken.
- an object that is not referenced "from the outside", but
  still referenced from a cycle. It will not be released immediately,
  but will be released eventually when the cyclic GC runs.
- an object that is part of a cycle, but not even released by
  the cyclic GC.
- an object that is never released because its reference counter
  is wrong.

Except for the last category, none of these are "true" leaks,
since you could always arrange to release them eventually through
explicit Python code.

> I played with other flags as DEBUG_SAVEALL, but I think they are not
> useful for what I want.

DEBUG_LEAK includes DEBUG_SAVEALL; all objects in cycles are not
released, but added to gc.garbage. This is to detect whether
you have objects that are not released even when they become
unreachable, but only when the GC runs. Some people consider
this a leak, and DEBUG_LEAK helps you to find such objects
(so you can break the cycles explicitly).

If you want to know whether you have objects that participate
in cycles and are not released by the cyclic GC, then don't
set any flags, and just look at gc.garbage.

> Finally, in this group I have seen a reference to an article in which
> they had the look to gc.garbage after calling explicitally to
> gc.collect(). is this necessary?

Necessary to do what? If you want to verify that all unreferenced
objects are collectable, you should check gc.garbage after invoking
gc.collect().

Regards,
Martin