Feature #1411
closedteuthology: scan valgrind log for badness
0%
Description
the memory leak stuff and stupid library issues aside, i don't remember seeing any false warnings from valgrind. is it feasible to raise teuth errors based on entries in the valgrind log? maybe make it optional or something?
i'm sure we have lots of little things that are triggered by stuff in our qa suite, but it'll be easiest to find it if a flag is raised automagically, by including a valgrind yaml fragment with a full suite run.
Updated by Sage Weil over 12 years ago
- Translation missing: en.field_position set to 8
Updated by Colin McCabe over 12 years ago
Valgrind can be run in a mode where it outputs XML.
generally, you would do it like this:
valgrind --xml=yes --xml-file=/tmp/file ...
The output from this mode is slightly harder to read than the normal mode, but the nice thing is that errors are enclosed by nice big 'error' XML tags.
There is a full description of the XML format here:
http://cpansearch.perl.org/src/VPIT/Test-Valgrind-1.12/samples/xml-output-protocol4.txt
It may be enough for us to check the return code from something like this:
grep --with-filename '<error>' valgrind_log_*.txt
Updated by Sage Weil over 12 years ago
- Translation missing: en.field_story_points set to 1
- Translation missing: en.field_position deleted (
29) - Translation missing: en.field_position set to 28
Updated by Sage Weil over 12 years ago
As soon as this is done (and/or as a test) let's do a full suite run with valgrind on (maybe one daemon at a time) and see if anything comes up.
Updated by Greg Farnum over 12 years ago
Hmm, I'm actually seeing a few errors in the MDS and OSD just by starting them up and shutting them down. (eg, vstart) Probably in config setup but we should take care of them before we try a full suite run!
Updated by Greg Farnum over 12 years ago
- Status changed from New to Resolved
Pushed a simple one in 3a3c859f5bc8691891ff8a0f67a960a0d538083e