gc.DEBUG_LEAK and gc.garbage

[Cesar]

Hi,

I am new with python, and I am having a look to program that leaks.
The first thing I have to do is to determine if what leaks it is the
python code of my company.

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). I am not
totally sure (see below).

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

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?

Thanks, Cesar

[Skip Montanaro]

Re: gc.DEBUG_LEAK and gc.garbage


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

That suggests to me that you have objects with __del__ methods that are
involved in cycles. Get rid of the __del__ methods or figure out some way
to break the cycles.

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

Generally, no, but if you want to make sure the collector has run when you
want to look at gc.garbage it's convenient to call gc.collect() first.

Skip

[Martin v. Löwis]

Re: gc.DEBUG_LEAK and gc.garbage

Cesar wrote:[color=blue]
> 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).[/color]

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.
[color=blue]
> I played with other flags as DEBUG_SAVEALL, but I think they are not
> useful for what I want.[/color]

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.
[color=blue]
> 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?[/color]

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