Yes. A lot of the leaks are in the unit test code. But I've found 2 legitimate leaks as well.
Phil ________________________________ From: John Ralls <jra...@ceridwen.us> To: Christian Stimming <christ...@cstimming.de> Cc: gnucash-devel@gnucash.org; Phil Longstaff <phil.longst...@yahoo.ca> Sent: Monday, May 21, 2012 4:56:52 PM Subject: Re: Running unit tests under valgrind On May 21, 2012, at 1:42 PM, Christian Stimming wrote: > Am Montag, 21. Mai 2012, 13:30:11 schrieb John Ralls: >> On May 21, 2012, at 11:36 AM, Phil Longstaff wrote: >>> I already found one memory leak and one uninitialized variable when >>> running the libqof/qof unit tests under valgrind. Can we set up all >>> unit tests to run with valgrind automatically? >> I don't think we want to impose the performance hit for doing that by >> default: Unit tests need to run quickly so that they're used after every >> change. A 20X slowdown would mean that nobody would use them. >> >> What's more, ISTM leaks in unit tests aren't a big deal anyway. Unit test >> programs are small and exit almost immediately. A leak will do no harm at >> all. (Some of the "make check" tests are another matter entirely.) >> >> As for uninitialized variables, the compiler will find those if you build >> with -Wall -Werror. No need to take Valgrind's performance hit for that. > > I think Phil's suggestion is a very valid idea in order to find memory leaks > inside the functions that are being tested. On the other hand, I agree with > Derek and John in that using valgrind doesn't make much sense as a default > when running the unittests. Hence, I think it would be good to provide some > infrastructure for optionally running the tests with valgrind. But it > shouldn't be added as a normal testing step that needs to be performed by > everyone who is running the tests. OK, though a leak in a unit test doesn't necessarily mean that the application leaks, nor does the absence of a leak in the unit test guarantee that the application doesn't leak. Regards, John Ralls _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
