[Python-Dev] Valgrind on 2.2.2

Michael Gilfix mgilfix@eecs.tufts.edu
Mon, 28 Oct 2002 20:00:29 -0500


  This should help shed some light on the situation:

Quoth the docs:

"""
For each such block, Valgrind scans the entire address space of the
process, looking for pointers to the block. One of three situations
may result:

  * A pointer to the start of the block is found. This usually
  indicates programming sloppiness; since the block is still pointed
  at, the programmer could, at least in principle, free'd it before
  program exit.

  * A pointer to the interior of the block is found. The pointer
  might originally have pointed to the start and have been moved
  along, or it might be entirely unrelated. Valgrind deems such a
  block as "dubious", that is, possibly leaked, because it's unclear
  whether or not a pointer to it still exists.

  * The worst outcome is that no pointer to the block can be
  found. The block is classified as "leaked", because the programmer
  could not possibly have free'd it at program exit, since no pointer
  to it exists. This might be a symptom of having lost the pointer at
  some earlier point in the program.
"""

  Possibly is the second case and definitely lost is the third case.
The definitely lost, in my experience, tends to mean you just forgot
to free a pointer. The possibly lost usually means that some memory
rot occurred, where it's not clear which pointer is causing the mem
leak.

                       -- Mike

On Mon, Oct 28 @ 19:37, Guido van Rossum wrote:
> >   Just been lurkin' :) Possibly lost means that Valgrind didn't see
> > any freeing for a specific point after a malloc. In valgrind terms,
> > you probably forgot to free a pointer and lost all points that could
> > reference that memory. In other words, a leak :) Usually 75% of those
> > errors can be solved locally within the function, although I haven't
> > looked at the specifics, but that 25% can get nasty.
> 
> Booh.
> 
> That statistic doesn't apply to Python -- there are no "simple" leaks
> left in Python's C code, the remaining ones are all nasty.
>
> Also, valgrind carefully distinguishes between "definitely lost" and
> "possibly lost".  What's the difference?
> 
> --Guido van Rossum (home page: http://www.python.org/~guido/)

-- 
Michael Gilfix
mgilfix@eecs.tufts.edu

For my gpg public key:
http://www.eecs.tufts.edu/~mgilfix/contact.html