Re: [Evolution-hackers] Memory leaks

[David Woodhouse <dwmw2 infradead org>]

On Mon, 2010-08-23 at 13:25 +0200, Milan Crha wrote: 
> 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?

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.

I'm now running in 'Massif', to see if that gives me anything
interesting.

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

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

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?

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

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.

But basically, what you seem to be saying is that Valgrind is
essentially useless for us. 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.


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

I'm running Evo under Valgrind -- if I were to look into *all* of the 67
mailing list folders that have unread mail in them, I'd get nothing else
done today. I only looked back in this folder because I happened to
notice a reference to your reply on the IRC channel, half an hour later.

Conversations go slowly enough at times, with people being spread around
the world in different time zones, that it really doesn't help if they
get delayed by half and hour or more at a time because you drop the
participants from Cc.

Note that I also didn't Cc you intentionally, because I know (and at
this particular moment I remember) *your* preference and it would be
kind of rude to *deliberately* go against it.

-- 
dwmw2