This is the generalized version of the `ChannelCapability` type, which has now
been moved into XPCOM so it can be used by other types. The functionality and
checking should be identical.
Differential Revision: https://phabricator.services.mozilla.com/D242845
While much of this is simply converting code (and removing extraneous
`size` parameters), toolkit/xre/GeckoArgs.{h,cpp} has some significant
changes to support sending read-only handles (which is all we need!).
Differential Revision: https://phabricator.services.mozilla.com/D236750
While much of this is simply converting code (and removing extraneous
`size` parameters), toolkit/xre/GeckoArgs.{h,cpp} has some significant
changes to support sending read-only handles (which is all we need!).
Differential Revision: https://phabricator.services.mozilla.com/D236750
The case in question is where the process exits before the timeout
expires and it's a forkserver child. Previously (before bug 1658072)
there wouldn't be a log message in this case, but otherwise the effect
was the same: if a process with the given pid was still running, it
would be sent `SIGKILL`.
Differential Revision: https://phabricator.services.mozilla.com/D237857
This adds a new type, `SharedMemoryCursor`, as well as platform support
for mapping subregions of shared memory handles. This type will attempt
to map the entire shared memory region, and will back off on the size of
the region until it can successfully map a portion of the region to read
data from.
Ideally, this should help reduce the chances of encountering memory
fragmentation issues when sending large JS structured clone buffers over
IPC.
Differential Revision: https://phabricator.services.mozilla.com/D233116
This adds a new type, `SharedMemoryCursor`, as well as platform support
for mapping subregions of shared memory handles. This type will attempt
to map the entire shared memory region, and will back off on the size of
the region until it can successfully map a portion of the region to read
data from.
Ideally, this should help reduce the chances of encountering memory
fragmentation issues when sending large JS structured clone buffers over
IPC.
Differential Revision: https://phabricator.services.mozilla.com/D233116
Replaced all instances of `MOZ_ALIGNOF` with `alignof` and removed said function. Removed `MOZ_ALIGNAS_IN_STRUCT` (unused since bug 1572205).
Differential Revision: https://phabricator.services.mozilla.com/D230730
If a process is exiting, currently the fork server will collect it
asynchronously from the parent process, so the `kill(handle, 0)` call
will succeed but attempts to read its status via procfs can fail (either
`open`ing or `read`ing the `stat` file). Because this can happen in
normal operation, we shouldn't log about it on release builds, but debug
builds will still log just in case it fails for an unexpected reason.
Differential Revision: https://phabricator.services.mozilla.com/D233315
Given that libevent's signal handling code is known to have race
conditions, and there are fundamental issues that make it hard to fix
upstream, and previous patches have removed our last usage of it, we
should assert that it's no longer used.
Differential Revision: https://phabricator.services.mozilla.com/D141312
This patch rewrites the Unix backend of ProcessWatcher for two reasons:
1. To remove the use of libevent's signal handling, which has concurrency
bugs that can't be easily fixed upstream (see Bugzilla for details)
2. To simplify the code in general; in particular, the new version has one
place where the process and its exit status are consumed from the OS
The new implementation uses the same pipe-to-self technique as libevent
(and which we use elsewhere) to deal with async signal safety. Unlike
the previous version, there is a single object which manages all
monitored child processes rather than one each. (Previously, this
multiplexing was done inside libevent.)
Differential Revision: https://phabricator.services.mozilla.com/D141309
This patch rearranges the abstraction around `waitpid`/`waitid`. There
is now a function `WaitForProcess` that returns more detailed information
about the process status, and then a wrapper `IsProcessDead` which is
private to the `ProcessWatcher` which simplifies the results and logs
information to stderr. In the future, the extended information could be
exposed to observers within Gecko in some way.
Differential Revision: https://phabricator.services.mozilla.com/D230468
Given that libevent's signal handling code is known to have race
conditions, and there are fundamental issues that make it hard to fix
upstream, and previous patches have removed our last usage of it, we
should assert that it's no longer used.
Differential Revision: https://phabricator.services.mozilla.com/D141312
This patch rewrites the Unix backend of ProcessWatcher for two reasons:
1. To remove the use of libevent's signal handling, which has concurrency
bugs that can't be easily fixed upstream (see Bugzilla for details)
2. To simplify the code in general; in particular, the new version has one
place where the process and its exit status are consumed from the OS
The new implementation uses the same pipe-to-self technique as libevent
(and which we use elsewhere) to deal with async signal safety. Unlike
the previous version, there is a single object which manages all
monitored child processes rather than one each. (Previously, this
multiplexing was done inside libevent.)
Differential Revision: https://phabricator.services.mozilla.com/D141309
This patch rearranges the abstraction around `waitpid`/`waitid`. There
is now a function `WaitForProcess` that returns more detailed information
about the process status, and then a wrapper `IsProcessDead` which is
private to the `ProcessWatcher` which simplifies the results and logs
information to stderr. In the future, the extended information could be
exposed to observers within Gecko in some way.
Differential Revision: https://phabricator.services.mozilla.com/D230468
I noticed and fixed a couple of bugs in our Linux setproctitle,
introduced by an earlier patch to copy part of the environment back into
the initial env space to make it readable from `/proc/{pid}/environ`:
1. The env vars were being written to the wrong point in the buffer and
would overwrite the end of the cmdline string (if it was longer than
the original args, which it generally is in our use case).
2. The comparison with the elements of `kEnvSkip` was passing the wrong
value to strncmp, so we might not skip the env vars we intended to.
Differential Revision: https://phabricator.services.mozilla.com/D232146
Previously the handling for the IO thread was split between
BrowserProcessSubThread (a replication of the background thread infrastructure
used by Chromium during the IPC import, which is only used for the IO thread in
Gecko), and IOThreadChild (a wrapper around ChildThread, which was imported
from Chromium's source).
This meant that there was little code-sharing between the parent and child
processes, and that the lifecycle of the IO thread was perhaps less clear.
This refactors the code to centralize handling of these threads, and provide a
basic common interface. At the moment, actually hooking up async IO listeners
is still done using the Chromium interfaces.
Differential Revision: https://phabricator.services.mozilla.com/D227739
Previously the handling for the IO thread was split between
BrowserProcessSubThread (a replication of the background thread infrastructure
used by Chromium during the IPC import, which is only used for the IO thread in
Gecko), and IOThreadChild (a wrapper around ChildThread, which was imported
from Chromium's source).
This meant that there was little code-sharing between the parent and child
processes, and that the lifecycle of the IO thread was perhaps less clear.
This refactors the code to centralize handling of these threads, and provide a
basic common interface. At the moment, actually hooking up async IO listeners
is still done using the Chromium interfaces.
Differential Revision: https://phabricator.services.mozilla.com/D227739
MOZ_RUNINIT => initialized at runtime
MOZ_CONSTINIT => initialized at compile time
MOZ_GLOBINIT => initialized either at runtime or compile time, depending on template parameter, macro parameter etc
This annotation is only understood by our clang-tidy plugin. It has no
effect on regular compilation.
Differential Revision: https://phabricator.services.mozilla.com/D223341
This patch also uses `MFD_ALLOW_SEALING` unconditionally, even if we're
not planning to seal the memfd, because `MFD_NOEXEC_SEAL` implies it.
(We could re-add `F_SEAL_SEAL` explicitly in that case but I don't think
it makes a meaningful difference in our use cases.)
Differential Revision: https://phabricator.services.mozilla.com/D222575
The situation that the zombie check from bug 1881386 was added for is
applicable to our CI but not to normal use. We do sometimes detect
zombie processes in normal operation, but this isn't inherently a
problem. Therefore, the log message for this is made debug-only to avoid
confusion for users of release builds.
Also, a comment added in bug 1881386 was missing the bug number; this has
been fixed.
Differential Revision: https://phabricator.services.mozilla.com/D226863
This builds on the support from bug 1440207 to allow passing mach ports into
new content processes. This is done using the existing initial mach IPC already
used to transfer a mach task port to the parent process on child process
creation.
Differential Revision: https://phabricator.services.mozilla.com/D221708
