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