On Mon, Jul 30, 2007 at 10:19:17PM +0100, Daniel P. Berrange wrote:
> On Mon, Jul 30, 2007 at 10:14:25PM +0100, Daniel P. Berrange wrote:
> > I ran 'make valgrind' for the first time in too long and found a hanful of
> > memory leaks in code exercised by the test suite. The attached patch fixes
> > them all.
>
> BTW, someone might have the answer for a question about valgrind. No matter
> what args I try, it consistently exits with a status code of '0' even if
> there are memory leaks
--error-exitcode=1
--error-exitcode=<number> [default: 0]
Specifies an alternative exit code to return if Valgrind
reported any errors in the run. When set to the default value
(zero), the return value from Valgrind will always be the return
value of the process being simulated. When set to a nonzero
value, that value is returned instead, if Valgrind detects any
errors. This is useful for using Valgrind as part of an
automated test suite, since it makes it easy to detect test
cases for which Valgrind has reported errors, just by inspecting
return codes.
> $ valgrind --leak-check=full --error-exitcode=1 ./qemuxml2xmltest
Hum, then that sounds like a bug ! I would report it, I'm afraid though
that they may consider this a non-runtime error, and then not apply the
error exit code path.
> ==14631== Memcheck, a memory error detector.
> ==14631== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al.
> ==14631== Using LibVEX rev 1658, a library for dynamic binary translation.
> ==14631== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
> ==14631== Using valgrind-3.2.1, a dynamic binary instrumentation framework.
> ==14631== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.
> ==14631== For more details, rerun with: -v
> ==14631==
Also add --quiet to avoid the extra verbosity in the regression tests
(that's my only feature to valgrind so I kind of like it :-)
[...]
> Notice how there are 16 chunks of memory which are definitely lost, but
> it still reports 0 errors in its 'ERROR SUMMARY' section, and exits as
> if it were successful. Any one know how to make 'do the right thing' if
> it finds leaks & return a non-zero status ? Makes it very hard to put
> into the makefile for automated error detection[1].
>
> Dan.
>
> [1] I really don't want to parse its 'LEAK SUMMARY" output.
What I did with 'make valgrind' in libxml2 is use the --quiet option,
output the error to a file and test for a zero size. No parsing, still
relatively simple at the shell level.
Daniel
--
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard | virtualization library http://libvirt.org/
veillard@xxxxxxxxxx | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list