We want to link PHC directly alongside jemalloc so move its code into the
memory/build/ directory. This means that it's always statically linked even
when other replace_malloc libraries aren't.
The following patch will remove it from the replace_malloc configuration.
Differential Revision: https://phabricator.services.mozilla.com/D188983
This change adds the PHCManager class which observes a pref to control PHC.
The pref can be changed at runtime and will affect the parent and content
processes.
Differential Revision: https://phabricator.services.mozilla.com/D178754
This change adds the PHCManager class which observes a pref to control PHC.
The pref can be changed at runtime and will affect the parent and content
processes.
Differential Revision: https://phabricator.services.mozilla.com/D178754
PHC can get stuck if sAllocDelay passes 0 while it is disabled. sAllocDelay
wraps (it's a uint32_t) and will take a long time to reach 0 again.
This patch will reset sAllocDelay if necessary when PHC is re-enabled.
Differential Revision: https://phabricator.services.mozilla.com/D181422
Improve the chance that we catch memory errors with PHC by:
* Increasing the number of PHC slots (increased from 64 to 4096 in most
cases).
* Lower the delay for the first PHC allocation, with more slots we can
afford to trap allocations from earlier in Firefox's startup.
These improve the chance PHC has of catching an error by 64x, at the cost of
additional 1MB of allocation metadata (on 4KB page size systems). It
shouldn't impact performance more than having PHC on at all.
This patch was originally developed by Randell Jesup.
Differential Revision: https://phabricator.services.mozilla.com/D161934
This changes replace_malloc_usable_size to allow measuring the size of
ptrs that appear anywhere within an allocation page, not just ptrs to the
start of the allocation pages.
This also modifies a gtest to explicitly check the usable size of some
modified pointers, not just the usable size of the pages where those
pointers are located.
Differential Revision: https://phabricator.services.mozilla.com/D170963
Add the customary bevy of thread-safety annotations to the Mutex types
in memory/build.
Almost all existing instances of these Mutexes are already marked with
MOZ_UNANNOTATED, but this turns out not to matter: MOZ_UNANNOTATED has
no equivalent under clang's `-Wthread-safety` attributes. There are no
variables declared to be guarded by these mutexes, but they must still
be unlocked and relocked in principled ways -- or, alternatively, only
have unverifiable actions taken in appropriately-annotated code.
The primary offenders here are the `pthread_atfork` hooks; these can't
all be annotated precisely (and couldn't be checked even if they were),
so we simply mark them all as unanalyzable. The only other warning is
from a highly unusual (but already well-commented) bit in PHC.cpp where
we manually release an autolocked mutex before crashing.
Differential Revision: https://phabricator.services.mozilla.com/D150519
Add the customary bevy of thread-safety annotations to the Mutex types
in memory/build.
Almost all existing instances of these Mutexes are already marked with
MOZ_UNANNOTATED, so there's not much else required for this patch. The
sole exception is a highly unusual (but already well-commented) bit in
PHC.cpp where we manually release an autolocked mutex before crashing.
Differential Revision: https://phabricator.services.mozilla.com/D150519
macOS unfair locks enforce that a lock can only be released by the thread which locked it.
On macOS 11+ this caused the fork()'d child process to raise a SIGILL signal. Confusingly enough this behavior seems to be different on macOS 10.15 and possibly interacted in odd ways with our exception handler if it was installed before fork()-ing.
Differential Revision: https://phabricator.services.mozilla.com/D148287
Sylvestre Ledru