Certain tests (many are from lld/test) run `... '2>&1 | count 0` to
ensure that there is no stderr message.
GetRegistersAndSP may rarely fail, leading to
a spurious failure like (with a local hack to make `count` dump the
input):
```
+ /home/ray/llvm/out/asan/bin/ld.lld func1-gcs.o func2-gcs.o func3-gcs.o -o /dev/null -z gcs-report=warning -z gcs=never
+ /home/ray/llvm/out/asan/bin/count 0
Expected 0 lines, got 1.
==2403039==Unable to get registers from thread 2403018.
```
The failure can reliably be reproduced by running `ninja check-lld` a
few times under asan+lsan (see the bot
sanitizer-x86_64-linux-bootstrap-asan).
For such threads we have no registers, so no exact
stack range, and no guaranties that stack is mapped
at all.
To avoid crashes on unmapped memory,
`MemCpyAccessible` copies intersting range into
temporarily buffer, and we search for pointers there.
The goal is to move `SuspendedThreadsList` related code into
the beginning of the loop, and prepare for extraction the rest
of the loop body into a function.
There are hard to debug leaks which look like
false.
In general, repeating leak checking should not
affect set of leaks significantly, especial
`at_exit` leak checking.
But if we see significant discrepancy, it may give
us a clue for investigation.
Fixes asan, msan crash on check added in #108684.
The #108684 includes reproducer of the issue.
Change interface of `GetThreadStackAndTls` to
set `tls_begin` and `tls_end` at the same time.
`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).
C++11 `alignas` is already used extensively. `alignas` must precede
`static`, so adjust the ordering accordingly.
msan.cpp: Clang 15 doesn't allow `__attribute__((visibility("default"))) alignas(16)`.
Use the order `alignas(16) SANITIZER_INTERFACE_ATTRIBUTE`. Tested with Clang 7.
Pull Request: https://github.com/llvm/llvm-project/pull/98958
We can use an internal linkage variable to make it clear the variable is
not exported. The special section .preinit_array is a GC root.
Pull Request: https://github.com/llvm/llvm-project/pull/98584
They are checked in the parent CMakeLists in
`compiler_rt_build_runtime` and `compiler_rt_test_runtime`.
There are non-redundant checks when a sanitizer checks
for the presense of another one. They should not be removed.
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.
We already have `const uptr kMaxAllowedMallocSize = 1ULL << 40;` set for
ASAN, HWASAN, memprof, TSAN. This patch bumps the malloc limit for MSAN,
LSAN and DFSAN to 1TB as well. 8GB is simply not enough nowadays.
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.
This is preparation for performance optimization.
We need to highlight that this is very specific lock, and should not be
used for other purposes.
Add `fork_child` parameter to distinguish processes after fork.
Prior to this, we would check if the end of the allocator cache was located
before the end of the chunk passed to the tls check. However, if the actual
allocator cache comes after the end of the chunk, then the sub in the
`end - params->allocator_caches[i]` bit overflows. Since the resulting type
is an unsigned uptr, this is not UB, but if the signed result would be a
negative value (ie. `end < params->allocator_caches[i]`) then this will
actually result in a very large unsigned value much bigger than the compared
`sizeof(AllocatorCache)` which will almost always be true. This can cause
ScanRangeForPointers to accept incorrect values: a begin pointing to some
address, and `params->allocator_caches[i]` pointing to some much larger
address way past the end of the chunk which can result in a page fault/stack overflow.
Differential Revision: https://reviews.llvm.org/D159518
When scanning over TLS regions, we attempt to check if one of the regions is
one of the thread_local allocator caches which would be located in one of the
TLS blocks pointer to by the DTV. This is to prevent marking a pointer that was
allocated by the primary allocator (from a thread_local cache) as reachable. The
check is a simple bounds check to see if the allocator cache is within the
bounds of one of the TLS block we're iterating over, but it looks like the check
for the end of the cache is slightly incorrect.
Differential Revision: https://reviews.llvm.org/D156015
This patch uses similar allocator configuration to Asan, i.e. dynamic
allocator start address (~(uptr)0) and 128 GB allocator size.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D152895
Before this patch when running HWASAN on x86_64 with with memory tagging support we got a bunch of false memory leak reports. The reason for that is that the heuristic used to detect if an 8 bytes could be a user pointer was not valid when memory tagging is used as the top byte could contain non-zero information.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D155338
