On Tue, 2008-03-25 at 20:58 +0100, Patrick Ohly wrote: > Hello, > > as part of the nightly testing that I mentioned recently I now also > started to run evolution-data-server and the test program under > valgrind, including --leak-check=yes. That covers the file backends for > calendar and contacts, libical, libecal and libebook. I run with > GLIBCXX_FORCE_NEW=1 G_SLICE=always-malloc G_DEBUG=gc-friendly
Oh Patrick, you are doing an awesome job for Evolution. > > My main motivation is to catch memory leaks inside the client program. > Because I neither have the time nor the necessary insights to clean up > Evolution itself, I rather aggressively suppress all valgrind reports > which don't seem to be caused by my own code. I attach the current > suppression file, just in case that a) another client developer is in > the same situation or b) some of the Evolution developers are interested > in the errors that are found (full stack traces are included as > comments; there are quite some leaks, but also uninitialized memory > accesses). All tests were done with a nightly build of Evolution trunk > on Debian Etch over a period of the last few weeks (I could only work on > it occasionally). The best is that if you could track it down to Evolution, file a bug with the valgrind traces and CC me there. > > Some of the leaks could be explained by SyncEvolution not freeing > resources when it should; unfortunately this does not always show up > with a backtrace that includes the code in SyncEvolution because the > background thread allocates the memory. Is the following code the right > way to free the results of the individual calls? This is what I > currently use after each and every such call that SyncEvolution makes > itself, but I still see leaks for memory allocated in > build_change_list() from libecal. > The addressbook code seems right to me. -Srini _______________________________________________ Evolution-hackers mailing list [email protected] http://mail.gnome.org/mailman/listinfo/evolution-hackers
