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 Woodhouse Open 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
