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

Question

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.