Re: [Valgrind-users] Using valgrind from a test suite

[Nicholas N. <nj...@ca...>]

On Wed, 26 Mar 2003, Olly Betts wrote:

> I had a brief discussion with Julian back in April 2002 about using
> valgrind as part of an automated testsuite for a library.

> My idea was to add a call or two so that the testsuite could be run
> under valgrind and the test harness could find out about problems
> from valgrind and fail the test in question.

> The testsuite needs to be able to test if memory has been leaked (so it
> can fail that test) and it would be useful to be able to totally
> suppress valgrind's output for that check when running in the
> testsuite's terse mode - it would just print "test7: FAIL (MEMORY LEAK)"
> or something similar.
>
> And if a test has failed with a memory leak or valgrind error, we want
> to be able to reset valgrind's counters so we can move onto the next
> test and not have the same problem re-reported.

>   int VALGRIND_SILENT(int silent);
>
>     If silent is non-zero, suppress *all* output from valgrind.  Returns
>     the setting prior to the call.
>
>   VALGRIND_READ_COUNTERS(int *errors, int *lost, int *possiblylost,
> 			 int *reachable);
>
>     Read counters into pointed to variables.  A pointer can be zero if
>     you aren't interested in a particular value.
>
>   VALGRIND_RESET_COUNTERS
>
>     Zeros error and leak counters.

I don't entirely understand what you want to do.

Does your entire test suite run as a single process under a single
invocation of Valgrind?  If so do you use --trace-children for the
individual tests?

I assume your three functions are client requests...  would they be
inserted into your test harness program, or the test programs themselves?

I guess you want to do something like: run valgrind in silent mode, after
each test read the counters to see if any leaks occurred and if so print
out the "terse" failure message, then reset them before going onto the
next test.

I would have thought it better for your test harness to run each test
program under Valgrind separately, maybe using --quiet (although leak
reports still get printed), and then maybe parse the output to see if any
leaks occurred.  Then counters wouldn't need to be reset at all.  But
maybe I'm missing something about what you want to do.

N