Re: Is -fsanitize=address working?

On Wed, 1 Oct 2025, Mouse wrote:

> So what to do?
>
> I think the best option is a variant of (3): respec CLOFORK.  I can
> think of four plausible respecs: (a) CLOFORK applies to fork(), not
> clone() [...]
>

Yeah, this is what I was thinking: these are different syscalls, right?
And, it's O_CLOFORK, not O_CLOCLONE. Should clone(2) do any checking at all?

If, after a clone(2) the child or parent does fork(2), then yeah, O_CLOFORK
should apply.

> (a) is problematic for applications that want to use clone() for one of
> the other ways it differs from fork() but want fork()-like open file
> table semantics.
>

I'm scratching my head trying to figure out what sort of applications these
would even be... :)

Anyway, off-list, kre@ mentioned a different workaround (for now), viz.:
`#define O_CLOFORK 0' when compiling tzcode.

I have another, assuming Thomas only wanted the AddressSanitizer, and not
the LeakSanitizer too: turn off the LeakSanitizer on NetBSD:

https://github.com/NetBSD/src/blob/trunk/external/gpl3/gcc.old/dist/libsanitizer/lsan/lsan_common.h#L48

NetBSD is unusual, among the free Unixes, in building the LeakSanitizer (and,
only because it has a clone(2)). None of the other BSDs, nor Solaris, have
it.

On Wed, 1 Oct 2025, Robert Elz wrote:

> 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.
>

Linux doesn't support O_CLOFORK at all, at the mo': not linux-6.17--the latest;
not glibc, nor musl. No such constant anywhere.

-RVP