Re: Is -fsanitize=address working?

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Tue, 30 Sep 2025 22:16:51 +0000 (UTC)
    From:        RVP <rvp%SDF.ORG@localhost>
    Message-ID:  <51ab75b7-9901-4fce-1fa4-e35ec042179e%SDF.ORG@localhost>

  | Thomas, can you try again after commenting out that test in kern_fork.c (r1.232)?

I doubt that is a great idea, though who knows what might happen.

The combination of an open fd with CLOFORK set, and clone (which
is just another fancy way of saying fork()) and CLONE_FILES set
really makes no sense, and we have no way of knowing what the linux
kernel will eventually do when they implement O_CLOFORK (if they
have done that recently, discovering what they did would be useful).

CLONE_FILES means that the fd table remains untouched (is shared)
between the processes, there can't be differences in the fd's between
the two.

CLOFORK says that after a fork, the fd should be open in the parent
and closed in the child.

Those two are simply incompatible.    There are certainly other options,
than EINVAL though.

We could ignore the CLONE_FILES (which is represented as FORK_SHAREDFILES
in that code) and just give the two processes different fd sets.

We could close the fd in both processes - but I doubt that would be
appreciated (particularly in this case).

We could silently turn off CLOFORK for any fds it is set on (which would
make this work just like it does on systems which do not implement
that yet) - but without the application having any way of knowing that.

We could just do nothing, and leave the fd open in both with O_CLOFORK
set (essentially meaning that CLOFORK is ignored in this case).   But I'm
not sure that the rest of code is truly compatible with that result, it
might be - it has certainly never been tested.

And whatever we do, if we do something now, before the linux kernel
people do, has just a smallish chance of being compatible with what they
end up doing.

kre