Re: [Valgrind-developers] [Valgrind-users] Valgrind-3.28.0.RC1 is available for testing

[Mark W. <ma...@kl...>]

Hi Collin,

On Wed, Oct 21, 2026 at 06:48:03PM -0700, Collin Funk wrote:
> You wrote:
> > none/tests/fdleak_cat                    (stderr)
> >
> > There is indeed a file descriptor "leak" in the latest coreutils
> > cat. So this isn't a valgrind bug.
> 
> In coreutils-9.11, Pádraig and I wrote the code to have it use splice
> where possible. This requires opening a pipe even when the input and/or
> output are pipes, in order to differentiate between read/write errors.
> We leave this pipe open across files if it can be left empty between
> each file.

Yes, that is what the test is detecting:

$ valgrind -q --track-fds=yes cat /dev/null
==34== FILE DESCRIPTORS: 3 open (1 inherited) at exit.
==34== Open file descriptor 5:
==34==    at 0x49D7B2D: pipe (pipe.c:29)
==34==    by 0x400888B: pipe_safer (pipe-safer.c:33)
==34==    by 0x400888B: splice_cat (cat.c:578)
==34==    by 0x40048CE: main (cat.c:899)
==34== 
==34== Open file descriptor 4:
==34==    at 0x49D7B2D: pipe (pipe.c:29)
==34==    by 0x400888B: pipe_safer (pipe-safer.c:33)
==34==    by 0x400888B: splice_cat (cat.c:578)
==34==    by 0x40048CE: main (cat.c:899)
==34== 

> This also means leaking the file descriptors should be okay, since they
> should be empty when reading the file and writing it to standard output
> is successful. I.e., calling close to check for errors on the pipe is
> not important.

Yes, this is a bit like still reachable memory at program exit, it
isn't a "real" leak. Unfortunately for file descriptors it is hard to
track whether they are still "reachable" (they are just small
integers). --track-fds=yes assumes that you want to close all
descriptors you opened (but ignores leaking inherited file
descriptors, use --track-fds=all for that).

> I wasn't aware that would cause issues in Valgrind tests, or else I
> probably would have closed them. If there's anything I can do to help,
> please feel free to let me know.

Although it would be great if you could just clean up and close these
descriptors, we probably should just write our own little cat like
program. We just picked cat since it seemed all implementations always
closed all file descriptors it opened. But coreutils cat is more
complicated than that.

That said you might want to run valgrind --track-fds=yes (or maybe
just --track-fds=bad which only reports on bad file descriptor usage,
not "leaking" fds) in the coreutils testsuite. It really is pretty
useful for catching possible file descriptor misuse.

Cheers,

Mark