The -ldl flag was previously set globally, it's now set for the libs
that use it.
Also rationalize the difference between HAVE_DLOPEN and HAVE_DLFCN_H.
Differential Revision: https://phabricator.services.mozilla.com/D203594
The -ldl flag was previously set globally, it's now set for the libs
that use it.
Also rationalize the difference between HAVE_DLOPEN and HAVE_DLFCN_H.
Differential Revision: https://phabricator.services.mozilla.com/D203594
The -ldl flag was previously set globally, it's now set for the libs
that use it.
Also rationalize the difference between HAVE_DLOPEN and HAVE_DLFCN_H.
Differential Revision: https://phabricator.services.mozilla.com/D203594
This memory was previously measured as part of committed memory. However
depending on the OS it will often not be committed. It's more accurate to
count it separately as part of mozjemalloc's cache of unused pages.
This patch adds counters for both fresh and madvised memory and no-longer
counts either as "committed" as it previously did.
This has the side effect of changing decisions based on the size of this
cache such as when to purge memory.
Differential Revision: https://phabricator.services.mozilla.com/D200415
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
Since mozglue is now aware of Gecko process-types, remove the
configurator for this bug's associated experiment. Instead, use
`GeckoProcessType` directly in mozjemalloc.
This requires a couple of adjustments for non-Firefox uses of
mozjemalloc:
- Since `logalloc-replay` uses mozjemalloc in an odd way, tweak its
`moz.build` to also include `mozglue/misc/ProcessType.cpp`.
- Since `GeckoProcessType` is not available in standalone SpiderMonkey
builds, make the mostly-arbitrarily choice to always stall there.
No functional changes.
Differential Revision: https://phabricator.services.mozilla.com/D155300
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
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
While mingw builds don't require user32 and advapi32 explicitly, it doesn't
hurt for them to be there (and they're required for clang-cl build).
Likewise, while clang-builds don't require uuid and userenv explicitly
because they're pulled in via #pragmas in the source code, mingw doesn't
support those #pragmas and needs them explicitly, which doesn't hurt the
clang-cl builds.
Differential Revision: https://phabricator.services.mozilla.com/D134737
While mingw builds don't require user32 and advapi32 explicitly, it doesn't
hurt for them to be there (and they're required for clang-cl build).
Likewise, while clang-builds don't require uuid and userenv explicitly
because they're pulled in via #pragmas in the source code, mingw doesn't
support those #pragmas and needs them explicitly, which doesn't hurt the
clang-cl builds.
Differential Revision: https://phabricator.services.mozilla.com/D134737
For a unified it is possible to include FdPrintf.cpp before FdPrintf.h which
creates a compilation warning for FdPrintf's attributes. FdPrintf.cpp
should include FdPrintf.h so that the declaration always precedes the
definition.
Depends on D132913
Differential Revision: https://phabricator.services.mozilla.com/D132914
jemalloc_stats takes an array for its second argument. It expects this
array to have enough space for all the bins, previously the maximum was set
as a magic number. To make it dependent on the configured bins this patch
replaces the compile-time constant with a function.
Differential Revision: https://phabricator.services.mozilla.com/D127761
The codeql initialization process causes a loop in allocator
initialization that results in the inability to issue open()
calls due to function interception having begun set-up but
not completing it. (More details in bug.)
Differential Revision: https://phabricator.services.mozilla.com/D120521
isspace requires data in libc to be initialised. If we're parsing
/proc/smaps before libc has initialised we need to provide our own
implementation.
Differential Revision: https://phabricator.services.mozilla.com/D116338
It was already disabled for fuzzed code-coverage in bug 1695331. My
guess is that fuzzed code-coverage tripped on the extra allocations
due to the code-coverage runtime, but the code-coverage builds didn't
trip it because they also triggered an exception, which further
triggered a bug in the code with python3 (and somehow the fuzzed ccov
builds didn't trigger that). That bug effectively masked the failure.
Differential Revision: https://phabricator.services.mozilla.com/D117383
BP may contain the stack address where the caller's BP was pushed after the function call, in which case it's possible to carefully unwind from it.
This can get past JIT code, so there is no need to give up in this case.
mozglue was already linked with ntdll, but now that we use it directly (for `NtQueryInformationThread`), ntdll needed to be added to some other users of MozStackWalkThread.
Differential Revision: https://phabricator.services.mozilla.com/D115962
Replay, moajemalloc_info, phc, and memory needed additional
pieces (mostly Printf.cpp and dependencies) to build
successfully on Windows.
Depends on D114651
Differential Revision: https://phabricator.services.mozilla.com/D114652
serge-sans-paille