Re: [Evolution-hackers] checking Evolution with valgrind

[Srinivasa Ragavan <sragavan novell com>]

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