Re: [Valgrind-developers] Failing regression tests

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

Hi Paul,

On Fri, 2025-09-05 at 07:43 +0200, Paul Floyd via Valgrind-developers
wrote:
> I agree with all that where the value of the fd is under the control of 
> the developer. I don't agree when it isn't. At least, not always.
> 
> Take this little example
> 
> truss bash -c "echo foo 22>&1" | grep 22
> 
> (swap truss for strace on a Linux system)
> 
> It looks like bash is checking that fd 22 is valid with
> 
> fcntl(22, F_GETFD, 0x00000000)                  Err#9 EBADF
> 
> Are we saying that bash developers shouldn't use --track-fds because 
> they sanitise inputs?
> 
> Valgrind gives
> 
> ==105408== File descriptor 22 was never created
> ==105408==    at 0xFFFEDEE5B: _syscall6 (in /lib/amd64/libc.so.1)
> ==105408==    by 0xFFFEC7071: fcntl (in /lib/amd64/libc.so.1)
> ==105408==    by 0x4BCF4C: ??? (in /usr/bin/bash)
> ==105408==    by 0x4BD5E3: do_redirections (in /usr/bin/bash)
> ==105408==    by 0x45CAAA: ??? (in /usr/bin/bash)
> ==105408==    by 0x45E5EC: execute_command_internal (in /usr/bin/bash)
> ==105408==    by 0x4C85E7: parse_and_execute (in /usr/bin/bash)
> ==105408==    by 0x441CA1: ??? (in /usr/bin/bash)
> ==105408==    by 0x442F06: main (in /usr/bin/bash)
> 
> On our side it is difficult for us to tell whether calls like fstat and 
> fcntl are being used like this to check inputs (not a programming error) 
> from a bug where the fd is bogus (which is a programming error).

OK, you convinced me there might be situations where you want to check
a number is a valid file descriptor. Even though I believe you could in
theory know by using the same trick valgrind uses [*]. But you are
right that a shell might have users try to do these kind of redirection
of (inherited) file descriptor tricks.

So I think that how bash checks here, using the F_GETFD fcntl, is
probably is the (only?) correct way of checking for valid fds. And we
should probably not warn about fcntl (fd, F_GETFD) by default. I am a
little reluctant to ignore using invalid file descriptors in other ways
though.

> I don't particularly like the idea of always ignoring fd errors for 
> these syscalls either.
> 
> I suggest that we just wait and see. If anyone complains we can think 
> about adding an option like --check-exist-fd-syscalls="fcntl,fstat" 
> (where the syscall name matching would be a bit complicated).

That is an interesting suggestion. Also --track-fds produces "core
errors" which are suppressible. But currently you cannot suppress on
syscall name, but maybe we can somehow make that possible.

Cheers,

Mark

[*] On startup, when --track-fds is given valgrind goes through
/proc/<pid>/fds/ to see which file descriptors got inherited. Those are
your initial set of valid file descriptors (which include 0,1,2
stdin/out/err). After that you should do bookkeeping when you create
new or destroy file descriptors. But... currently a program doing that
actually doesn't work under valgrind, which is the bug Alexandra is
fixing atm: https://bugs.kde.org/show_bug.cgi?id=331311