The only consumer of this code was Singleton, which we previously
removed, and everything that this code accomplished can be done more
simply and more foolproof-y by standard constructs these days.
Most of the times when we automatically create nsThread wrappers for threads
that don't already have them, we don't actually need the event targets, since
those threads don't run XPCOM event loops. Aside from wasting memory, actually
creating these event loops can lead to leaks if a thread tries to dispatch a
runnable to the queue which creates a reference cycle with the thread.
Not creating the event queues for threads that don't actually need them helps
avoid those foot guns, and also makes it easier to figure out which treads
actually run XPCOM event loops.
MozReview-Commit-ID: Arck4VQqdne
--HG--
extra : source : a03a61d6d724503c3b7c5e31fe32ced1f5d1c219
extra : intermediate-source : 5152af6ab3e399216ef6db8f060c257b2ffbd330
extra : histedit_source : ef06000344416e0919f536d5720fa979d2d29c66%2C4671676b613dc3e3ec762edf5d72a2ffbe6fca3f
Most of the times when we automatically create nsThread wrappers for threads
that don't already have them, we don't actually need the event targets, since
those threads don't run XPCOM event loops. Aside from wasting memory, actually
creating these event loops can lead to leaks if a thread tries to dispatch a
runnable to the queue which creates a reference cycle with the thread.
Not creating the event queues for threads that don't actually need them helps
avoid those foot guns, and also makes it easier to figure out which treads
actually run XPCOM event loops.
MozReview-Commit-ID: Arck4VQqdne
--HG--
extra : rebase_source : fcf8fa50e748c4b54c3bb1997575d9ffd4cbaae1
extra : source : a03a61d6d724503c3b7c5e31fe32ced1f5d1c219
Most of the times when we automatically create nsThread wrappers for threads
that don't already have them, we don't actually need the event targets, since
those threads don't run XPCOM event loops. Aside from wasting memory, actually
creating these event loops can lead to leaks if a thread tries to dispatch a
runnable to the queue which creates a reference cycle with the thread.
Not creating the event queues for threads that don't actually need them helps
avoid those foot guns, and also makes it easier to figure out which treads
actually run XPCOM event loops.
MozReview-Commit-ID: Arck4VQqdne
--HG--
extra : rebase_source : 02c5572b92ee48c11697d90941336e10c03d49cf
As the comments indicate, it has unavoidable race conditions in a
multithreaded program, and its call sites have all been removed.
Differential Revision: https://phabricator.services.mozilla.com/D6561
--HG--
extra : moz-landing-system : lando
This change is mainly to avoid the use of SetAllFDsToCloseOnExec, which
has an unavoidable race condition that can leak file descriptors into
child processes. The "Linux" implementation of child process creation,
now that B2G support has been removed, is essentially a generic Unix
fork+dup2+execve which works on BSD (and is already used on Solaris).
In the MinGW browser build job, we're going to use -fms-extensions,
which will tell clang to start processing these comments. Clang
cannot process them correctly (it's an upstream bug) but it doesn't
need to, because we include the libs we need in moz.build files.
So we exclude them for MinGW builds. mingw-clang gets them wrong and
mingw-gcc (which doesn't even work anymore on -central) ignored them.
In the future, with a llvm fix, we could clean up the moz.build
files and re-enable these comments.
Differential Revision: https://phabricator.services.mozilla.com/D3527
--HG--
extra : moz-landing-system : lando
Closures are nice but -- as pointed out in bug 1481978 comment #2 --
it's a footgun to take a std::function argument in a context where heap
allocation isn't safe.
Fortunately, non-capturing closures convert to C function pointers,
so a C-style interface with a void* context can still be relatively
ergonomic.
This introduces the machinery needed to generate crash annotations from a YAML
file. The relevant C++ functions are updated to take a typed enum. JavaScript
calls are unaffected but they will throw if the string argument does not
correspond to one of the known entries in the C++ enum. The existing whitelists
and blacklists of annotations are also generated from the YAML file and all
duplicate code related to them has been consolidated. Once written out to the
.extra file the annotations are converted in string form and are no different
than the existing ones.
All existing annotations have been included in the list (and some obsolete ones
have been removed) and all call sites have been updated including tests where
appropriate.
--HG--
extra : source : 4f6c43f2830701ec5552e08e3f1b06fe6d045860
This replaces using file_util to open and unlink temporary files
(/dev/shm on Linux, $TMPDIR or /tmp otherwise) with the POSIX shm_open
API, or ashmem on Android (which doesn't implement shm_open).
glibc maps shm_open/shm_unlink to open and unlink in /dev/shm (as does
musl libc), so the Linux situation is mostly unchanged except we aren't
duplicating code from system libraries. Other OSes may (and some do)
use more efficient implementations than temporary files.
FreeBSD's SHM_ANON extension is used if available. Sadly, it's not
standard; it would make this patch much simpler if it were.
This patch changes the shm file names; they now start with "org.mozilla"
instead of "org.chromium" because the original Chromium code is mostly
gone at this point. When running as a Snap package, the required
filename prefix is added; other container/sandbox environments using
AppArmor to restrict the allowed filenames may need to be adjusted.
The shm names now include the creating process's pid, to allow
using sandboxing to prevent interfering with shm belonging to other
applications or other processes within the same browser instance.
MozReview-Commit-ID: 7PirIlcblh4
The current code is somewhat non-obvious to a first-time reader, and
OS_TEST is a bizarre thing anyway, since it's actually the name of the
CPU we're running on. We'd do well to minimize the use of OS_TEST.
Note that the complete nuking of the xptcall/md/unix/moz.build lines are
because we don't support OS X/x86 anymore.
These are no longer providing useful information. There are still a
noticeable number of failures on Windows, but we've narrowed them down to
within SandboxBroker::LaunchApp.
MozReview-Commit-ID: 9srWLNZq1Wo
--HG--
extra : rebase_source : db44114a7623e75f9efd629046d2118748352ed1
This replaces some old Chromium code that tries to minimally disentangle
an arbitrary file descriptor mapping with simpler algorithm, for several
reasons:
1. Do something appropriate when a file descriptor is mapped to the same
fd number in the child; currently they're ignored, which means they'll
be closed if they were close-on-exec. This implementation duplicates
the fd twice in that case, which seems to be uncommon in practice; this
isn't maximally efficient but avoids special-case code.
2. Make this more generally applicable; the previous design is
specialized for arbitrary code running between fork and exec, but we
also want to use this on OS X with posix_spawn, which exposes a very
limited set of operations.
3. Avoid the use of C++ standard library iterators in async signal safe
code; the Chromium developers mention that this is a potential problem in
some debugging implementations that take locks.
4. In general the algorithm is simpler and should be more "obviously
correct"; more concretely, it should get complete coverage just by being
run normally in a debug build.
As a convenient side benefit, CloseSuperfluousFds now takes an arbitrary
predicate for which fds to leave open, which means it can be used in
other code that needs it without creating a fake fd mapping.
MozReview-Commit-ID: EoiRttrbrKL
--HG--
extra : rebase_source : 336e0ba9f56dc80f7347dc62617b4ad1efea7e7e