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.
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
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
The method cache stashes a mask in the high bits under some circumstances:
689525d556/runtime/objc-cache.mm (L589)
I'm hitting this now on macOS 13.4 arm64, so we can no longer rely on OBJC_FAST_IS_RW to identify potential pointers that need to be transformed
Differential Revision: https://reviews.llvm.org/D153471
Usually root_regions size is small so unlikey
this change will provide a noticable difference.
However it's easy to make sure that even with
large number of root_regions it works reasonably
fast.
Differential Revision: https://reviews.llvm.org/D151781
This caused false positives because the existing logic was not taking into account that pointers could have a tag in them.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D144305
For HWASAN this would be the tagged address. It is the same pointer when pointer tagging is not used. Coincidently this also fixes some test which rely on comparing pointers.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D143121
Main goal is to remove thread registry dependency from the interface because HWASAN is using its own code to manage threads.
Reviewed By: vitalybuka, kstoimenov
Differential Revision: https://reviews.llvm.org/D140039
Main goal is to remove thread registry dependency from the interface because HWASAN is using its own code to manage threads.
Reviewed By: vitalybuka, kstoimenov
Differential Revision: https://reviews.llvm.org/D140039
As shown in https://github.com/llvm/llvm-project/issues/42932 dead
pointers might be overlapped by a new stack frame inside CheckForLeaks,
which does not use bytes with pointers. This leads to false negatives.
It's not a full solution for the problem as it does not solve
"overlapping" new/old frames for frames below the CheckForLeaks and in
other threads. It should improve leaks found in direct callers of
__lsan_do_leak_check.
Differential Revision: https://reviews.llvm.org/D130237
Detailed motivation here: https://docs.google.com/document/d/1xUNo5ovPKJMYxitiHUQVRxGI3iUmspI51Jm4w8puMwo
check-asan (with LSAN enabled) and check-lsan are currently broken on recent macOS versions, due to pervasive false positives. Whenever the Objective-C runtime realizes a class, it allocates data for it, then stores that data with flags in the low bits. This means LSAN can not recognize it as a pointer while scanning.
This change checks every potential pointer on Apple platforms, and if the high bit is set, attempts to extract a pointer by masking out the high bit and flags. This is ugly, but it's also the best approach I could think of (see doc above); very open to other suggestions.
Differential Revision: https://reviews.llvm.org/D133126
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
While attempting to get the 64-bit lsan allocator working for Fuchsia, I
noticed this function would incorrectly return false for pointers returned
by the 64-bit allocator. On AArch64, this function attempts to get the VMA
size dynamically by counting the number of leading zeros from the function
frame address. This will fail if the frame address is significantly below an
allocated pointer (that is, the frame address has more leading zeros than an
allocated pointer). This is possible on Fuchsia and linux (when not called
from the initial thread stack).
It seems the intended use of this function is to speed up pointer scanning by
filtering out addresses that user code might not be able to access. Other
platforms this check is done on seem to hardcode the VMA size/shift, so it
seems appropriate to do this for aarch64 as well. This implies pointers on
aarch64 where the VMA size is <64 will pass through, but bad pointers will
still be caught by subsequent scan checks.
This patch also renames the function to something more fitting of what it's
trying to do.
Differential Revision: https://reviews.llvm.org/D123814
If sanitizer cannot determine name of the module it
will use "<unknown module>". Then it can be suppressed
if needed.
Reviewed By: kda
Differential Revision: https://reviews.llvm.org/D121674
This removes the last use of StackDepot from StopTheWorld.
Depends on D115284.
Reviewed By: morehouse
Differential Revision: https://reviews.llvm.org/D115319
