Criterion using file descriptors without consent

[Ximaz]

I was using Valgrind over my unit tests in order to check for memleaks and unclosed file descriptors. Here is one of the output I get for every single test that gets executed :

==83== FILE DESCRIPTORS: 6 open (3 std) at exit.
==83== Open file descriptor 4:
==83==    at 0x4E8F96D: pipe (pipe.c:29)
==83==    by 0x4A0D3A2: stdpipe_options (in /usr/local/lib/libcriterion.so.3.2.0)
==83==    by 0x4A1A97E: cr_redirect (in /usr/local/lib/libcriterion.so.3.2.0)
==83==    by 0x4A1AB02: cr_redirect_stdin (in /usr/local/lib/libcriterion.so.3.2.0)
==83==    by 0x4A151C5: run_test_child (in /usr/local/lib/libcriterion.so.3.2.0)
==83==    by 0x4A25A59: bxfi_main (in /usr/local/lib/libcriterion.so.3.2.0)
==83==    by 0x4DB5B89: (below main) (libc_start_call_main.h:58)
==83== 
==83== Open file descriptor 17: /dev/shm/bxf_arena_25 (deleted)
==83==    <inherited from parent>
==83== 
==83== Open file descriptor 16: /dev/shm/bxf_arena_25 (deleted)
==83==    <inherited from parent>
==83==

Valgrind flags are those :

-s --leak-check=full --track-origins=yes --read-var-info=yes --trace-children=yes --show-leak-kinds=all --read-inline-info=yes --errors-for-leak-kinds=all --track-fds=yes --show-reachable=yes

The thing I don't understand is the Valgrind's report about the cr_redirect_stdin not closing it's fd, same for /dev/shm/bxf_arena_25 that I don't even know what it does.

I'm not using cr_redirect_stdin anywhere in my tests, I'm not even including the criterion/redirect.h header file. Also, I'm not opening any file or socket inside both my tests AND my implementations. I don't know where those FDs come from, but I have no idea how to ignore them with Valgrind, and it appears there is nothing related to FDs in Valgrind's documentation for Suppressions Files.

Thanks in advance for your help.

[MrAnno]

Hi @Ximaz,

Thanks for opening this issue.

Criterion follows the KISS principle, however, under the hood, it does some truly exciting and complex things to ensure that each test case can run in isolation (sandboxed test cases; crashes, and signals can be reported and tested, etc.). The implementation details of this sandboxed environment are why you see /dev/shm file descriptors during test execution.

Nevertheless, leaking file descriptors or memory is not okay; these issues need to be fixed.