valgrind --track-fds=yes exit code 0 even when there are FD leaks

Viewed 59

I am trying to set up a CI that will fail if file descriptors leak is detected. Here is a simple test:

$ valgrind --quiet --track-fds=yes --error-exitcode=1 ./hello_world
hello world!
$ echo $?
0

$ valgrind --quiet --track-fds=yes --error-exitcode=1 ./hello_world_leak
hello world!
==889092== FILE DESCRIPTORS: 4 open (3 std) at exit.
==889092== Open file descriptor 3: /tmp/vg-test/main.cpp
==889092==    at 0x4B968DB: open (open64.c:48)
==889092==    by 0x109249: main (in /tmp/vg-test/hello_world_leak)
==889092== 
==889092== 
$ echo $?
0

(the --quiet option supresses the output if 3 std FDs are the only non-closed FDs on exit, which is fine).

As you see, even with --error-exitcode=1 and the FD leak in the program, the valgrind exits with code 0.

My next idea on how to make it work was to write valgrind output to a file, then parse it check if it contains the FILE DESCRIPTORS string:

$ valgrind --quiet --track-fds=yes --error-exitcode=1 --log-file=/tmp/valgrind_out.log ./hello_world
hello world!
$ cat /tmp/valgrind_out.log
==891904== FILE DESCRIPTORS: 4 open (3 std) at exit.
==891904== Open file descriptor 3: /tmp/valgrind_out.log
==891904==    <inherited from parent>
==891904==

But here comes the next problem: the file opened for valgrind output (/tmp/valgrind_out.log) is considered open at exit! Same happens when I tee the valgrind's stderr output to a file.

So the only solution I came up with was to parse the output and check that there are exactly 4 open (3 std) FDs at exit. Are there any less ugly solutions?

EDIT: I've created a wrapper script that does precisely that: github.com/Roman-/valgrind-wrapper. Still looking forward for more elegant solutions.

0 Answers
Related