tech-toolchain archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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


Home | Main Index | Thread Index | Old Index