[Evolution-hackers] Memory leaks
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. But there are *lots* of reports of memory blocks being 'possibly lost', too. Should we be worrying about those? See http://valgrind.org/docs/manual/mc-manual.html#mc-manual.leaks for a coherent description of what 'possibly lost' means -- basically it means that the objects *might* be reachable, but not through direct pointers. They're only reachable through pointers which point somewhere *inside* the allocated block, and would only ever be freed if we do some kind of pointer arithmetic magic to recalculate the allocated pointer and free the block. The Valgrind manual calls these 'interior-pointers', and says this of them and the 'possibly lost' case: This could just be a random value in memory that happens to point into a block, and so you shouldn't consider this ok unless you know you have interior-pointers. I'm therefore tempted to go ahead and file bugs for *every* report of 'possibly lost' that Valgrind gives me when I run Evolution. 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. What do you think? -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Memory leaks
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 evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Memory leaks
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 ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Memory leaks
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 evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Specifications for kolab plugin development
Hi! We wanted to announce our current development for the Kolab plugin for EDS/Evolution in form of the specifications paper to the Evolution hackers list. Any input, advice or hints are welcome! Unfortunately the document is in German language, so for now I will provide a html version for automated translations, too. PDF: http://sourceforge.net/projects/evolution-kolab/files/Feinkonzept_Anteil_KC_SecurMobI_v1_smf_2010-07-08.pdf/download A html Version for automated translation is available from: HTML: http://www.kernelconcepts.de/~silvan/evolution-kolab/Feinkonzept_Anteil_KC_SecurMobI_v1_smf_2010-07-08.html For translation: (http://translate.google.com) http://translate.google.com/translate?js=yprev=_thl=deie=UTF-8layout=1eotf=1u=http://www.kernelconcepts.de/~silvan/evolution-kolab/Feinkonzept_Anteil_KC_SecurMobI_v1_smf_2010-07-08.htmlsl=detl=en Kind regards, Silvan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
