Version: valgrind-3.2.1-4 (using KDE Devel) Installed from: Compiled sources OS: Linux Suppose I have a memory leak in a program ./foo and I do this: $ valgrind --leak-check=yes --quiet --error-exitcode=1 ./foo ;echo $? ==29367== ==29367== 3 bytes in 1 blocks are definitely lost in loss record 1 of 1 ==29367== at 0x4005400: malloc (vg_replace_malloc.c:149) ==29367== by 0x80483BC: main (foo.c:3) 0 $ Here there was a leak error (or perhaps its a warning). But the exit code isn't zero. I need some way to make that error code be nonzero. I'd be happy if this example simply returned 1 for $? I'd also be happy if there was another argument such as --warning-exitcode=1 if you think those are warnings rather than errors. Note: I'm not asking for the system to exit early if there is an error. I just need an automated test to be able to determine if there was a leak.
This would be quite the philosophical change for Valgrind, which generally never changes a program's behavior (or at least tries very hard not to.) The program did an "exit(0)" and that's what Valgrind is going to do. Probably what you want is the "-q" option, which would make Valgrind quiet unless there was an error or some sort. I don't recall if that's compatible with "--leak-check=yes" option, though (not near a suitable machine right now to check.)
I am afraid I don't understand your position. The --error-exitcode already violates your philosophical position. From the man page: 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. So the program does an exit(0) and that's not what valgrind returned. Now it is only a question of whether a detected leak qualifies as an "error" or not. I see two reasonable ways to fix this: 1) A detected leak is defined to be an error. In that case valgrind has a bug: it doesn't report it as an error, and doesn't return the right exit code. 2) A detected leak is defined something else (perhaps a warning.) In that case, I'm asking for a --warning-exitcode so that I can get the answer that I want. --quiet does not do the trick. I already use --quiet --error-exitcode=1 and that allows my test structure to detect errors. I don't think it's reasonable, however, for an automated test system to parse the output of the program to look for leak warnings. Much better would be to have leaks also reflected as an exit code.
My bad - I had no idea that flag existed.
I'd also like to vote for a way to have leaks result in an error exit code. Assuming leaks can be suppressed in system libraries, it would be very useful to be able to detect leaky programs through the exit code instead of having to parse the output like Bradley Kuszmaul suggested doing. Chris
Me too. I want to be able to signal an error in a test suite when a leak is detected. At the moment I can't see a way of doing this short of rigging up a wrapper that greps the output of valgrind. Ugh.
Bug 186790 is related to this.
Fixed as r10767.