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 _______________________________________________ evolution-hackers mailing list email@example.com To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers