| Summary: | leak errors produce an exit code of 0. I need some way to cause leak errors to result in a nonzero exit code. | ||
|---|---|---|---|
| Product: | [Developer tools] valgrind | Reporter: | Bradley C. Kuszmaul <kuszmaul> |
| Component: | general | Assignee: | Julian Seward <jseward> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | njn, rrt |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | wanted3.5.0 | ||
| Platform: | Compiled Sources | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Bradley C. Kuszmaul
2007-11-15 22:56:57 UTC
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. |