Bug 479661 - Valgrind leaks file descriptors
Summary: Valgrind leaks file descriptors
Status: CONFIRMED
Alias: None
Product: valgrind
Classification: Developer tools
Component: general (show other bugs)
Version: 3.22.0
Platform: Arch Linux Linux
: NOR normal
Target Milestone: ---
Assignee: Julian Seward
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-01-11 18:23 UTC by Wojciech Malecha
Modified: 2024-06-13 18:07 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Output of valgrind --trace-children=yes -v --track-fds=yes ./test (20.69 KB, text/plain)
2024-01-11 18:23 UTC, Wojciech Malecha
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Wojciech Malecha 2024-01-11 18:23:27 UTC
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.
Comment 1 Paul Floyd 2024-01-18 06:39:39 UTC
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>
Comment 2 Mark Wielaard 2024-06-13 17:56:13 UTC
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>
Comment 3 Mark Wielaard 2024-06-13 18:07:52 UTC
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.