`DTLS_on_libc_memalign` is called from primary
allocator, so `__sanitizer_get_allocated_begin`
should also be aware of allocation,
and correctly handled by `GetDTLSRange`.
Previously an attempt to free a null pointer during initialization would
fail on ENSURE_LSAN_INITED assertion (since a null pointer is not owned
by DlsymAlloc).
We use REAL() calls in interceptors, but
DEFINE_REAL_PTHREAD_FUNCTIONS has nothing to do
with them and only used for internal maintenance
threads.
This is done to avoid confusion like in #96456.
Most sanitizers don't support static linking. One primary reason is the
incompatibility with interceptors. `GetTlsSize` is another reason.
asan/memprof use `__interception::DoesNotSupportStaticLinking`
(`_DYNAMIC` reference) to reject -static at link time. Port this
detector to other sanitizers. dfsan actually supports -static for
certain cases. Don't touch dfsan.
Currently if a program calls sigaction very early (before non-lazy sanitizer
initialization, in particular if .preinit_array initialization is not enabled),
then sigaction will wrongly fail since the interceptor is not initialized yet.
In all other interceptors we do lazy runtime initialization for this reason,
but we don't do it in the signal interceptors.
Do lazy runtime initialization in signal interceptors as well.
Reviewed By: melver
Differential Revision: https://reviews.llvm.org/D155188
Most uses of ALIAS() are in conjunction with WRAPPER_NAME().
Simplify the code and just make ALIAS() turn its argument into a string
(similar to Linux kernel's __alias macro). This in turn allows removing
WRAPPER_NAME().
NFC.
Reviewed By: dvyukov
Differential Revision: https://reviews.llvm.org/D151216
Bionic uses pthread_exit to set retval, when GLIBC does not.
This cause double call to Finish. Rather then tracking this difference
on interceptor size, we can just relax precondition. It does not make
a difference.
This is a follow up to [Sanitizers][Darwin] Rename Apple macro SANITIZER_MAC -> SANITIZER_APPLE (D125816)
Performed a global search/replace as in title against LLVM sources
Differential Revision: https://reviews.llvm.org/D126263
It should be NFC, as they already intercept pthread_create.
This will let us to fix BackgroundThread for these sanitizerts.
In in followup patches I will fix MaybeStartBackgroudThread for them
and corresponding tests.
Reviewed By: kstoimenov
Differential Revision: https://reviews.llvm.org/D114935
They don't seem to do anything useful in lsan.
They are needed only if a tools needs to execute
some custom logic during detach/join, or if it uses
thread registry quarantine. Lsan does none of this.
And if a tool cares then it would also need to intercept
pthread_tryjoin_np and pthread_timedjoin_np, otherwise
it will mess thread states.
Fwiw, asan does not intercept these functions either.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D113920
Since glibc 2.34, dlsym does
1. malloc 1
2. malloc 2
3. free pointer from malloc 1
4. free pointer from malloc 2
These sequence was not handled by trivial dlsym hack.
This fixes https://bugs.llvm.org/show_bug.cgi?id=52278
Reviewed By: eugenis, morehouse
Differential Revision: https://reviews.llvm.org/D112588
Currently we have a bit of a mess related to tids:
- sanitizers re-declare kInvalidTid multiple times
- some call it kUnknownTid
- implicit assumptions that main tid is 0
- asan/memprof claim their tids need to fit into 24 bits,
but this does not seem to be true anymore
- inconsistent use of u32/int to store tids
Introduce kInvalidTid/kMainTid in sanitizer_common
and use them consistently.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D101428
This commit adds an interceptor for the pthread_detach function,
calling into ThreadRegistry::DetachThread, allowing for thread contexts
to be reused.
Without this change, programs may fail when they create more than 8K
threads.
Fixes: https://bugs.llvm.org/show_bug.cgi?id=47389
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D88184
This is a small refactoring to prepare for porting LSan to Fuchsia.
Factor out parts of lsan_thread.{cpp,h} that don't apply to Fuchsia.
Since existing supported systems are POSIX-based, the affected code
is moved to lsan_posix.{cpp.h}.
Patch By: mcgrathr
Differential Revision: https://reviews.llvm.org/D73309
This fixes buildbot failures for https://reviews.llvm.org/rL372459.
(at least on PowerPC/Z )
The fix is generated by running clang-format on the error lines only.
llvm-svn: 372511
Summary:
strerror(3) on NetBSD uses internally TSD with a destructor that is never
fired for exit(3). It's correctly called for pthread_exit(3) scenarios.
This is a case when a leak on exit(3) is expected, unavoidable and harmless.
Reviewers: joerg, vitalybuka, dvyukov, mgorny
Reviewed By: vitalybuka
Subscribers: dmgreen, kristof.beyls, jfb, llvm-commits, #sanitizers
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D67337
llvm-svn: 372461
Summary:
The atexit(3) and __cxa_atexit() calls allocate internally memory and free on exit,
after executing all callback. This causes false positives as DoLeakCheck() is called
from the atexit handler. In the LSan/ASan tests there are strict checks triggering
false positives here.
Intercept all atexit(3) and __cxa_atexit() calls and disable LSan when calling the
real functions.
Stop tracing allocations in pthread_atfork(3) funtions, as there are performed
internal allocations that are not freed for the time of running StopTheWorld()
code. This avoids false-positives.
The same changes have to be replicated in the ASan and LSan runtime.
Non-NetBSD OSs are not tested and this code is restricted to NetBSD only.
Reviewers: dvyukov, joerg, mgorny, vitalybuka, eugenis
Reviewed By: vitalybuka
Subscribers: jfb, llvm-commits, #sanitizers
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D67331
llvm-svn: 372459
