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