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
Breaks bots.
Also it's missing changes we discussed on review.
This reverts commit f001e50f955c3cdf2deb79e38a9fd19c9a781882.
This reverts commit 2924189233fdb724453ead4b94595107b1ce9cfa.
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
StackDepot locks some stuff. As is there is small probability to
deadlock if we stop thread which locked the Depot.
We need either Lock/Unlock StackDepot for StopTheWorld, or don't
interact with StackDepot from there.
This patch does not run LeakReport under StopTheWorld. LeakReport
contains most of StackDepot access.
As a bonus this patch will help to resolve kMaxLeaksConsidered FIXME.
Depends on D114498.
Reviewed By: morehouse, kstoimenov
Differential Revision: https://reviews.llvm.org/D115284
kIgnored didn't exist when the code was added, but it should be
equivalent to kReachable.
The goal is to refactor MarkInvalidPCCb to avoid StackDepotGet
in StopTheWorld.
Mutex does not support LINKER_INITIALIZED support.
As preparation to switching BlockingMutex to Mutex,
proactively replace all BlockingMutex(LINKER_INITIALIZED) to Mutex.
All of these are objects with static storage duration and Mutex ctor
is constexpr, so it should be equivalent.
Reviewed By: melver
Differential Revision: https://reviews.llvm.org/D106944
InternalScopedString uses InternalMmapVector internally
so it can be resized dynamically as needed.
Reviewed By: eugenis
Differential Revision: https://reviews.llvm.org/D98751
This mechanism is intended to provide a way to treat the `arg` pointer
of a created (but not yet started) thread as reachable. In future
patches this will be implemented in `GetAdditionalThreadContextPtrs`.
A separate implementation of `GetAdditionalThreadContextPtrs` exists
for ASan and LSan runtimes because they need to be implemented
differently in future patches.
rdar://problem/63537240
Differential Revision: https://reviews.llvm.org/D95183
This makes suppression list to work similar to __lsan_ignore_object.
Existing behavior was inconsistent and very inconvenient for complex
data structures.
Example:
struct B;
struct A { B* ptr; };
A* t = makeA();
t->ptr = makeB();
Before the patch: if makeA suppressed by suppression file, lsan will
still report the makeB() leak, so we need two suppressions.
After the patch: a single makeA suppression is enough (the same as a
single __lsan_ignore_object(t)).
Differential Revision: https://reviews.llvm.org/D93884
Reland: a2291a58bf1c860d026581fee6fe96019dc25440.
New fixes for the breakages reported in D85927 include:
- declare a weak decl for `dl_iterate_phdr`, because it does not exist on older APIs
- Do not enable leak-sanitizer if api_level is less than 29, because of `ld.lld: error: undefined symbol: __aeabi_read_tp` for armv7, API level 16.
- Put back the interceptor for `memalign` but still opt out intercepting `__libc_memalign` and `cfree` because both of these don't exist in Bionic.
Reviewed By: srhines, vitalybuka
Differential Revision: https://reviews.llvm.org/D89251
