Re: [Evolution-hackers] Memory leaks
- From: Milan Crha <mcrha redhat com>
- To: evolution-hackers gnome org
- Subject: Re: [Evolution-hackers] Memory leaks
- Date: Mon, 23 Aug 2010 16:32:22 +0200
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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]