Implement a drop-in-replacement wrapper for `VirtualAlloc` which, rather
than returning immediately on failure, instead `::Sleep()`s and retries.
This will cause performance regressions in some (presumed-uncommon)
circumstances; this wrapper is therefore only enabled in Nightly, to
collect data on its efficacy and on the severity of those regressions.
Differential Revision: https://phabricator.services.mozilla.com/D150619
Implement a drop-in-replacement wrapper for `VirtualAlloc` which, rather
than returning immediately on failure, instead `::Sleep()`s and retries.
This will cause performance regressions in some (presumed-uncommon)
circumstances; this wrapper is therefore only enabled in Nightly, to
collect data on its efficacy and on the severity of those regressions.
Differential Revision: https://phabricator.services.mozilla.com/D150619
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
I went through the docs and fixed up a few things. I also removed the other
version that was imported under XPCOM, updated a few obsolete MDN links that
now have updated docs, and deleted some ancient Bonsai links.
Differential Revision: https://phabricator.services.mozilla.com/D150504
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
-Wshadow warnings are not enabled globally, so these -Wno-shadow suppressions have no effect. I had intended to enable -Wshadow globally along with these suppressions in some directories (in bug 1272513), but that was blocked by other issues.
There are too many -Wshadow warnings (now over 2000) to realistically fix them all. We should remove all these unnecessary -Wno-shadow flags cluttering many moz.build files.
Differential Revision: https://phabricator.services.mozilla.com/D132289
Fabrice Desré
Andreea Pavel
Mark Banner
Ray Kraesig
Butkovits Atila
Paul Bone
Tooru Fujisawa
Gabriele Svelto
smolnar
Andrew McCreight
Ryan VanderMeulen
Bogdan Szekely
Marian-Vasile Laza
Serge Guelton
Randell Jesup
Noemi Erli
Zhao Jiazhong
Mike Hommey
Iulian Moraru
Chris Peterson
Gian-Carlo Pascutto