Re: [Evolution-hackers] Memory leaks

[Milan Crha <mcrha redhat com>]

On Mon, 2010-08-23 at 13:10 +0100, David Woodhouse wrote:
> On Mon, 2010-08-23 at 13:25 +0200, Milan Crha wrote: 
> https://bugzilla.gnome.org/showdependencytree.cgi?id=627707
> 
> I've grouped a bunch of different GtkHTML reports together. although I'm
> not sure that was the right thing to do.
> 
> The fixes I mentioned are sitting in my working tree, and I'll commit
> and push them today.

	Hi,
good, thanks for it.

> ...
> If they're referenced by a global variable, surely valgrind would know
> that they're reachable and would not complain about them?

I do not know how it works precisely.

> And if *not*, can we find a way to teach Valgrind that they're
> reachable, so that it can be useful for us and not have so many false
> positives?
> 
> ...
> I had thought briefly about annotating the code, and perhaps extending
> sparse to handle refcounts and 'ownership' of memory so that it can warn
> at compile time if you write code which leaks.

Hmm, I cannot imagine a way doing so with an async API. It would be a
very complex call tree to solve, with evo and eds code mixed together,
from my uneducated point of view (imagine all the libraries used in
them, and all using evo/eds).

> But basically, what you seem to be saying is that Valgrind is
> essentially useless for us.

I'm definitely not saying that. I like valgrind, it helps me (usually)
pretty well.

I just got a thought, what if some of those "possibly lost" come from
GSlice? Then G_SLICE=always-malloc should help valgrind with it. At
least a bit.

> I'd be very disappointed if that really
> turns out to be the case -- we should definitely talk to Julian about
> that before we give up.

I'm not giving up, and as stated above, I like valgrind :)
	Bye,
	Milan