Re: [Valgrind-developers] [valgrind] Add --modify-fds=[no|high] option

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

Hi Paul,

On Thu, 2025-04-17 at 08:31 +0200, Paul Floyd via Valgrind-developers
wrote:
> On 4/16/25 22:12, Paul Floyd via Valgrind-developers wrote:
> > 
> > 
> > The  track_new testcase isn't working on FreeBSD. If I add the 
> > POST_newFd_RES macro to POST(sys_openat)
> >  then I see the fds being assigned from VG_(fd_hard_limit) downwards 
> > but when ML_(fd_allowed)() is called from PRE(sys_write) I don't see 
> > that openbadfd->fd_closed is set for the closed fd.
> > 
> > Need more debugging of what's happening during close.
> 
> I think FreeBSD dprintf is being clever and seeing that the fd is 
> closed. Outside of Valgrind I was seeing a call to write() but not when 
> running under Valgrind.
> 
> I'll try using just plain write() rather than dprintf().

Interesting. Yeah, maybe dprintf is too clever/tricky to use in the
testcase. But the testcase picked this sequence of calls since it came
from some real code that triggered an issue (in highly parallel code).

Using plain write might be simpler to analyze what is going on.

But we do still have: https://bugs.kde.org/show_bug.cgi?id=493430
Review all syscalls (and ioctls) that use or return (new) file
descriptors

Given that there are multiple ways to open/create a file descriptor
(and sometimes an open call is turned into openat or creat), use a file
descriptor and close it we have to audit all syscalls to make sure the
call record_fd_open, fd_allowed and record_close when appropriate, and
for --modify-fds every syscall that creates a new filedescriptor must
have something like POST_newFd_RES or equivalent to make sure all newly
returned file descriptors uses a "high" number.

I think we did most generic and linux specific calls, but not any non-
linux specific ones (thanks for adding at least the open annotation on
solaris). On freebsd at least the POST(sys_openat) should get a
POST_newFd_RES added I think.

Cheers,

Mark