Created attachment 164819 [details] Output of valgrind --trace-children=yes -v --track-fds=yes ./test SUMMARY When running valgrind with --trace-children=yes --track-fds=yes on program uses fork and exec, valgrind reports open descriptors, even if the program does not open anything. CODE ```test.c #include <unistd.h> #include <sys/wait.h> int main(int argc, char **argv) { if (!fork()) { execlp("echo", "echo", NULL); } wait(NULL); return 0; } ``` STEPS TO REPRODUCE 1. Compile the code above: `gcc test.c -o test` 2. Run ` valgrind --trace-children=yes --track-fds=yes ./test` OBSERVED RESULT ==86569== Open file descriptor 10: ==86569== <inherited from parent> ==86569== ==86569== Open file descriptor 8: ==86569== <inherited from parent> EXPECTED RESULT Those descriptors should not be open. ADDITIONAL INFORMATION The full output with -v flag in attachment. output of uname -a: Linux pangolingila 6.6.7-arch1-1 #1 SMP PREEMPT_DYNAMIC Thu, 14 Dec 2023 03:45:42 +0000 x86_64 GNU/Linux This issue is not present in valgrind 3.19. I think the bug was introduced in commit 0432ce486d61f84f6fcbeab0d812bb1f61c57561.
commit details commit 0432ce486d61f84f6fcbeab0d812bb1f61c57561 Author: Alexandra Petlanova Hajkova <ahajkova@redhat.com> Date: Thu Mar 3 04:46:03 2022 -0500 vgdb: implement the extended-remote protocol Executing vgdb --multi makes vgdb talk the gdb extended-remote protocol. This means that the gdb run command is supported and vgdb will start up the program under valgrind. Which means you don't need to run gdb and valgrind from different terminals. Also vgdb keeps being connected to gdb after valgrind exits. So you can easily rerun the program with the same breakpoints in place. vgdb now implements a minimal gdbserver that just recognizes a few extended-remote protocol packets. Once it starts up valgrind it sets up noack and qsupported then it will forward packets between gdb and valgrind gdbserver. After valgrind shutsdown it resumes handling gdb packets itself. https://bugs.kde.org/show_bug.cgi?id=434057 Co-authored-by: Mark Wielaard <mark@klomp.org>
I see only one "leaked" file description for the echo command: ==1727176== FILE DESCRIPTORS: 2 open (1 std) at exit. ==1727176== Open file descriptor 9: ==1727176== <inherited from parent> But 3 (!?) when using -v: ==1727335== FILE DESCRIPTORS: 4 open (1 std) at exit. ==1727335== Open file descriptor 11: ==1727335== <inherited from parent> ==1727335== ==1727335== Open file descriptor 10: ==1727335== <inherited from parent> ==1727335== ==1727335== Open file descriptor 8: ==1727335== <inherited from parent>
I don't think it was the commit 0432ce ("vgdb: implement the extended-remote protocol") which seems to use CLOSEXEC correctly. It seems to be related to the pipe created for debuginfod support, commit fd4e3f ("PR432215 Add debuginfod functionality") which uses a "plain" pipe instead of a pipe2 with O_CLOEXEC flag. The issue goes away when doing unset DEBUGINFOD_URLS.