[Evolution-hackers] Memory leaks

[David Woodhouse <dwmw2 infradead org>]

I got offended by Evolution growing to almost 4GiB and having to be
killed if I wanted to use my workstation for anything else, so I've
started running it in Valgrind.

I've filed bugs for the reports of 'definitely lost', and have fixed a
bunch of them.

But there are *lots* of reports of memory blocks being 'possibly lost',
too. Should we be worrying about those?

See http://valgrind.org/docs/manual/mc-manual.html#mc-manual.leaks for a
coherent description of what 'possibly lost' means -- basically it means
that the objects *might* be reachable, but not through direct pointers.
They're only reachable through pointers which point somewhere *inside*
the allocated block, and would only ever be freed if we do some kind of
pointer arithmetic magic to recalculate the allocated pointer and free
the block.

The Valgrind manual calls these 'interior-pointers', and says this of
them and the 'possibly lost' case:

	This could just be a random value in memory that happens to
	point into a block, and so you shouldn't consider this ok unless
	you know you have interior-pointers.

I'm therefore tempted to go ahead and file bugs for *every* report of
'possibly lost' that Valgrind gives me when I run Evolution.

Even if some of them are false positives, I think we should find some
way to tell Valgrind about them -- either with a suppressions file, or
preferably by finding some annotation which lets Valgrind know that this
'interior-pointer' really *is* going to be followed.

Even if it means cleaning up some false positives, I think it would be
extremely useful to get to a point where valgrind runs cleanly and new
memory leaks can easily be detected.

What do you think?

-- 
David Woodhouse                            Open Source Technology Centre
David Woodhouse intel com                              Intel Corporation