Criterion icon indicating copy to clipboard operation
Criterion copied to clipboard

Criterion using file descriptors without consent

Open Ximaz opened this issue 2 months ago • 1 comments

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.

Ximaz avatar May 02 '24 04:05 Ximaz