Re: [Valgrind-users] New mem leak detection algorithm finds more bugs

[<sf...@ge...>]

On Thu, 30 Oct 2003, Nicholas Nethercote wrote:
> Have you considered more standard garbage collection algorithms, eg.
> tracing through all the reachable objects from a root set?  I think the
> algorithm you described might, in effect, do the same thing, but I wonder
> if doing it in a more straightforward GC-style way would be simpler?

I did consider it.  The actual code changes I made were surprisingly
minimal.  Creating a non-looping N-ary tree of references would involve
significantly additional coding with the only advantage being that it
would run faster for programs that exit with lots of non-freed blocks.
I decided it wasn't worth the effort or risk (of introducing bugs).


> > But maybe that is ok.  Good programmers free all their memory
> > before program exit.
> 
> Really?  Hmm.  Good programmers don't create space leaks either :)

Heh.  I never claimed to be a good programmer.  During 10+ years of
embedded programming, I considered it a mortal sin to not fully clean
up on exit.  Now, 5 years later, I'm appalled at how lazy I've gotten.

---

I just made an improvement that makes sure that a block won't be
counted as "reachable" unless it is either directly or indirectly
properly pointed to from non-heap memory.  In other words, if a
non-heap pointer points inside a block, it is set to possibly
lost.  If that block points at new block (either properly or
internally), that new block is set to possibly lost.  If a fully-reachable
block contains an interior pointer to a new block, that new block
is set to possibly lost.

Before this improvement, a lost linked list of blocks would show the
first block as lost (or possibly lost), but subsequent blocks in the
list would be shown as reachable.

I should be done testing tomorrow.