|
From: Darren C. <da...@dc...> - 2004-01-27 00:30:21
|
I'd like to use valgrind with some unit tests, which are structured such that any output is a test failure. I don't want suppressed blocks to count as a test failure, but unfortunately they cause output [1]. I tried with just -q and without --leak-check=yes, which does give no output, but there is also no output on real problems, so that is not an option. Is there a commandline option to do this? Or does anyone already have a bash script or similar to filter output? Thanks, Darren [1]: $ valgrind -q --leak-check=yes ./9.do_nothing_1.exe ==1548== searching for pointers to 3 not-freed blocks. ==1548== checked 4575400 bytes. ==1548== ==1548== LEAK SUMMARY: ==1548== definitely lost: 0 bytes in 0 blocks. ==1548== possibly lost: 0 bytes in 0 blocks. ==1548== still reachable: 0 bytes in 0 blocks. ==1548== suppressed: 4448 bytes in 3 blocks. ==1548== |
|
From: Avery P. <ape...@ni...> - 2004-01-27 01:51:38
|
On Tue, Jan 27, 2004 at 09:31:17AM +0900, Darren Cook wrote: > Is there a commandline option to do this? Or does anyone already have a > bash script or similar to filter output? [...] > $ valgrind -q --leak-check=yes ./9.do_nothing_1.exe > ==1548== searching for pointers to 3 not-freed blocks. > ==1548== checked 4575400 bytes. > ==1548== > ==1548== LEAK SUMMARY: Well, obviously filtering the output is rather trivial; first of all, your program's output goes to stdout (probably), while valgrind's goes to stderr. So you can just ignore the whole problem and pipe your program into your output detector as you normally would. valgrind myprogram | checkforjunk You could also do this, if you really need the stderr: valgrind myprogram 2>&1 | tee logfile.out \ | grep -v '^==[0-9]*==' | checkforjunk Or you could do what we do in our new-style wvstreams unit tests, and actually use valgrind's API (see the docs), explicitly checking valgrind's error count occasionally and reporting a failed test if valgrind's output isn't as expected. Good luck, Avery |
|
From: Darren C. <da...@dc...> - 2004-01-27 07:17:52
Attachments:
mac_leakcheck.c
|
>>Is there a commandline option to do this? Or does anyone already have a >>bash script or similar to filter output? > > Well, obviously filtering the output is rather trivial; first of all, your > program's output goes to stdout (probably), while valgrind's goes to stderr. The unit tests might write to stdout or stderr, but I can do this (where $1 is the program to test, and $2 is its output, which will be an empty file if the test passed): valgrind -q --logfile-fd=3 --leak-check=yes ./$1 > $2 2>&1 3>valgrind.log But now I need something to tell me if valgrind.log is noise or found a genuine problem. Looking at the output [1] I think I need a full program, not just a grep or perl one-liner. What I want is: valgrind --really-quiet --leak-check=yes ./$1 > $2 2>&1 Where the --really-quiet flag would output the full report if there was a leak which wasn't suppressed, and would do no output at all otherwise. I had a look at the memcheck code and did a crude hack of memcheck/mac_leakcheck.c which does exactly what I need. I've attached it if anyone is interested (my changes are at lines 410, 431, 517 and 538 - I warned you it was crude :-). Darren [1]: ==1480== searching for pointers to 3 not-freed blocks. ==1480== checked 4669432 bytes. ==1480== ==1480== LEAK SUMMARY: ==1480== definitely lost: 0 bytes in 0 blocks. ==1480== possibly lost: 0 bytes in 0 blocks. ==1480== still reachable: 0 bytes in 0 blocks. ==1480== suppressed: 4448 bytes in 3 blocks. ==1480== Reachable blocks (those to which a pointer was found) are not shown. ==1480== To see them, rerun with: --show-reachable=yes ==1480== |
|
From: Nicholas N. <nj...@ca...> - 2004-01-27 09:55:54
|
On Tue, 27 Jan 2004, Darren Cook wrote: > I'd like to use valgrind with some unit tests, which are structured such > that any output is a test failure. I don't want suppressed blocks to count > as a test failure, but unfortunately they cause output [1]. > > I tried with just -q and without --leak-check=yes, which does give no > output, but there is also no output on real problems, so that is not an option. > > [1]: > $ valgrind -q --leak-check=yes ./9.do_nothing_1.exe > ==1548== searching for pointers to 3 not-freed blocks. > ==1548== checked 4575400 bytes. > ==1548== > ==1548== LEAK SUMMARY: > ==1548== definitely lost: 0 bytes in 0 blocks. > ==1548== possibly lost: 0 bytes in 0 blocks. > ==1548== still reachable: 0 bytes in 0 blocks. > ==1548== suppressed: 4448 bytes in 3 blocks. > ==1548== You're right in that with -q, that output shouldn't be printed. And I just tried it, and that output wasn't printed. I tried both 2.0.0 and the current CVS HEAD. What version are you using? N |
|
From: Darren C. <da...@dc...> - 2004-01-28 00:03:37
|
>>$ valgrind -q --leak-check=yes ./9.do_nothing_1.exe >>==1548== searching for pointers to 3 not-freed blocks. >>==1548== checked 4575400 bytes. >>==1548== >>==1548== LEAK SUMMARY: >>==1548== definitely lost: 0 bytes in 0 blocks. >>==1548== possibly lost: 0 bytes in 0 blocks. >>==1548== still reachable: 0 bytes in 0 blocks. >>==1548== suppressed: 4448 bytes in 3 blocks. >>==1548== > > You're right in that with -q, that output shouldn't be printed. And I > just tried it, and that output wasn't printed. I tried both 2.0.0 and the > current CVS HEAD. What version are you using? 2.0.0. You can see from the file (memcheck/mac_leakcheck.c) I posted that it was not doing any checking before output. Does that file look different in CVS? Darren P.S. Valgrind has already found some genuine memory leaks in my project! |
|
From: Nicholas N. <nj...@ca...> - 2004-01-28 00:23:17
|
On Wed, 28 Jan 2004, Darren Cook wrote:
> > You're right in that with -q, that output shouldn't be printed. And I
> > just tried it, and that output wasn't printed. I tried both 2.0.0 and the
> > current CVS HEAD. What version are you using?
>
> 2.0.0. You can see from the file (memcheck/mac_leakcheck.c) I posted that it
> was not doing any checking before output. Does that file look different in CVS?
Ah, I'm looking at the 2.0.0 CVS branch, this must have been fixed since
2.0.0 was release. The fix was to wrap the bits of code doing the
printing inside a conditional like this:
if (VG_(clo_verbosity) > 0) {
...
}
Thanks for the report.
N
|