On Mon, Oct 28 @ 20:15, Guido van Rossum wrote:
> > * 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.
>
> Booh again. Lots of globals get initialized with pointers to
> malloc'ed blocks that are never freed. There are never called "leaks"
> in other leak detectors, just "alive at exit". I think valgrind
> actually doesn't call these leaks either.
I don't think valgrind reports this first case. Only the second and
third, from what I gathered in the docs.
> > 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.
>
> How much Python extension coding (in C) have you done? In Python, it
> almost never is a matter of forgetting to free() -- it's usually a
> matter of forgetting to DECREF, and sometimes a matter of doing an
> unnecessary INCREF.
I've done a fair bit, but to explain valgrind things, I figured it was
best to talk the valgrind talk. Either way, it comes to the same thing.
Glad that helped.
-- Mike
--
Michael Gilfix
mgilfix@eecs.tufts.edu
For my gpg public key:
http://www.eecs.tufts.edu/~mgilfix/contact.html
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4