Clean-up all of the calls and remove the redundant == 0 checks.
There is only one small visible change. For non-Android, the memalign
function will now fail if alignment is zero. Before this would have
passed.
In the StackDepot::isValid function, there is work to validate the
TabMask variable. Unfortunately, if TabMask is set to the maximum
allowed value, TabSize = TabMask + 1 becomes zero and validation passes.
Disallow that case to prevent invalid reads into the Tab structure.
First commit of the stack is a clean reland, second is the fix.
There was a typo in the `static_assert` that meant we were asserting the
size of the pointer, not the struct.
Also changed `alignas` to be more intuitive, but that is NFC.
Ran builds in Android here: https://r.android.com/2954411
Scudo grabs all allocator locks in a pthread_atfork before the fork, and releases them after. This allows malloc to be used in a fork child of a multithreaded process, which is expressly forbidden by the standard, but very widely used. For example, Android's init uses std::string after fork when spawning services in android::init::EnterNamespaces and other places.
Any lock that is necessary to serve an allocator call must be handled this way. Otherwise there is a possibility that the lock is held during the call to fork, which results in it being held forever in the child process, and the next operation that needs it deadlocks.
The stack depot uses several megabytes of memory
which is a lot for Trusty.
Reviewed By: Chia-hungDuan
Differential Revision: https://reviews.llvm.org/D156392
- we have clutter-reducing helpers for relaxed atomics that were barely
used, use them everywhere we can
- clang-format everything with a recent version
Differential Revision: https://reviews.llvm.org/D90649
Introduce a function __scudo_get_error_info() that may be called to interpret
a crash resulting from a memory error, potentially in another process,
given information extracted from the crashing process. The crash may be
interpreted as a use-after-free, buffer overflow or buffer underflow.
Also introduce a feature to optionally record a stack trace for each
allocation and deallocation. If this feature is enabled, a stack trace for
the allocation and (if applicable) the deallocation will also be available
via __scudo_get_error_info().
Differential Revision: https://reviews.llvm.org/D77283