Re: [Evolution-hackers] Memory leaks

[Milan Crha <mcrha redhat com>]

On Mon, 2010-08-23 at 11:12 +0100, David Woodhouse wrote:
> 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.

	Hi,
that's pretty bad. What are the bug numbers/links, please?

> But there are *lots* of reports of memory blocks being 'possibly lost',
> too. Should we be worrying about those?
> 
> ...
>
> I'm therefore tempted to go ahead and file bugs for *every* report of
> 'possibly lost' that Valgrind gives me when I run Evolution.

Please do not do that. Evolution has cache of CamelStore-s,
CamelFolder-s and such, so almost anything from evolution can be pointed
by some global/static variable. And indeed, these caches aren't freed by
the application, but by the operating system itself.

> 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.

I agree, though I'm afraid it's not possible (I didn't check valgrind
yet, but I do not suppose it has any compiler flags/annotations in the
code, because it uses the binary file itself, together with a debug
information). I can be wrong here, though.
	Bye,
	Milan

P.S.: I didn't CC you intentionally, because I know you are subscribed
on this list, and because I do not want anyone CC'ing me on this list,
because I'm subscribed to it too. ;)