Before this patch if we failed to launch the crash helper client then we
would either freeze or crash Firefox, which is not what we want. This
makes sure that errors when launching the crash helper are not
catastrophic. Additionally, this problem was triggered on a machine that
launched more than 64 child processes at startup during session restore.
That was a hard limit on Windows because of the limitations of
WaitForMultipleObjects(). I adjusted the code to also handle that
gracefully even though we don't support more than 64 child processes at
the moment. That's not a big deal because we're not yet using that
particular IPC channel, so ignoring every child process above the 63rd
doesn't change anything at the moment. Last but not least there was a
small race in the crash helper rendez-vous that might cause Linux to
attempt to generate a minidump before we had allowed a child process to
allow the crash helper to ptrace() it. This was also fixed.
Original Revision: https://phabricator.services.mozilla.com/D256299
Differential Revision: https://phabricator.services.mozilla.com/D262076
This channel is currently only used on Linux to rendez-vous with the
crash helper, obtain its PID and use it to enable the process to be
dumped when the Yama LSM is enabled. It will be used to actually request
a dump in the future, when the breakpad exception handler is removed.
Original Revision: https://phabricator.services.mozilla.com/D254047
Differential Revision: https://phabricator.services.mozilla.com/D262074
This changes a few IDs which have historically been 32-bit integers to
instead be 64-bit integers, reducing the chance of the value
overflowing.
Differential Revision: https://phabricator.services.mozilla.com/D250502
Ideally aAllowedFilePaths would be an array of nsIFile, but unfortunately
we don't seem to be able to pass nsIFile's over IPC, so pass the paths
instead. This should be fine for Windows but may need more testing or
a better solution if/when we support Mac.
Differential Revision: https://phabricator.services.mozilla.com/D248521
Because the fork server is used to remotely `waitpid` child processes,
and this can be done until very late in shutdown, this patch extends the
fork server's lifetime. This is a little complicated: it requires some
changes to `GeckoChildProcessHost::Destroy` to allow it to work after the
I/O thread is no longer accepting runnables.
Differential Revision: https://phabricator.services.mozilla.com/D240715
There are two parts to this:
1. A new sync IPC call to the fork server which is basically just
waitpid: it takes a pid and a flag for whether to block, and returns
either the exit status, an error, or an indication that the process is
still running. The code in the parent process which would previously
hack around the fork server case with `kill(pid, 0)` now uses this
instead.
2. The fork server now has a `SIGCHLD` handler which writes to a pipe
given at startup. Currently this is connected to the same pipe-to-self
used in `ProcessWatcher` for the parents' own `SIGCHLD`s. Thus, the
existing `ProcessWatcher` is mostly unmodified.
Measured locally, these remote `waitpid`s take about 50µs, compared to
about 10µs for in-process. So, while it's possible for the callback
for `SIGCHLD` pipe reads to call this `O(n)` times when `n` child
processes are exiting at once, the time taken shouldn't be a significant
responsiveness problem; I measured 250µs max while closing a tab for a
popular website with a large number of out-of-process iframes. This can
be optimized later to batch the messages if needed.
The other potential performance issue is if a remote `waitpid` is blocked
behind a remote fork. However, this is still an improvement over the
non-forkserver status quo: if we `clone` the parent process, that blocks
all threads for, empirically, about 15ms; cloning the fork server is
about 2.5ms, and that would only block another thread if it happens to
race with another child process exiting and not every time. We also
prelaunch content processes during idle time, so this type of jank is
less likely to be user-visible in any case.
Importantly, the way this patch works, the `waitpid` is synchronous with
respect to the thread in the parent process making the requeste, so as
long as the fork server hasn't crashed then we can know that the process
with a given pid is in fact the process we expect it to be.
Differential Revision: https://phabricator.services.mozilla.com/D240714
This does a few things to ForkServiceChild that will be needed in future
patches:
* protects the channel with a mutex, so that multiple threads can
make calls to the fork server; note that the fork server itself is
single-threaded so these are necessarily serialized
* ForkServiceChild is now thread-safely refcounted, so that attempts to
use it which race with a fork server crash/restart will fail safely
Differential Revision: https://phabricator.services.mozilla.com/D240713
Incoming messages to the ForkServiceChild are replies to its synchronous
requests to the fork server, read with blocking I/O, so handling the
reply can be done inline. And there will soon be several requests,
with different replies, so it doesn't make sense to have a single
OnMessageReceived method like this.
Differential Revision: https://phabricator.services.mozilla.com/D240712
In modern C++, static constexpr member variables are automatically
inline (aka weak) so the template trick is not needed. This also avoid
duplication and reduces the amount of parsed code. No impact on
generated binary (actually: smaller debuginfo, close to identical
binary).
Differential Revision: https://phabricator.services.mozilla.com/D247825
The current logic results in all `BACKGROUND_CHILD` process types ending
up as GPU processes (if they aren't an extension process), however
rather than rely on this behavior, it's a better idea to send the actual
process type name through to the Android crash handling code.
Differential Revision: https://phabricator.services.mozilla.com/D245979
This implements the crash helper service used to move child process crash
report generation out of the main process and into its own process. This is
implemented as a separate executable that is launched on startup by the main
process on the desktop platforms and as a service hosted by a separate process
on Android.
The crash helper process is started when the first exception handler is set
on desktop platforms and before loading libxul on Android. In both cases
starting this process happens asynchronously so that neither the main process
nor child processes have to wait for it to come up. If a crash happens before
the crash helper has started, the crashed process will wait for it to fully
come up and then proceed with regular crash generation.
IPC with the crash helper is implemented using Unix sockets on Linux and macOS
with the former using sequential packets and the latter using stream sockets.
On Windows we use named pipes. In all cases the choice of IPC was dictated both
by the requirement to eventually talk directly to child processes from within
the sandbox, and to external processes in case of Windows as the Windows
Error Reporting exception handler must be able to reach out to the helper from
within a restricted context. These particular requirements are not used yet but
will be as we move more logic out of the main process logic.
Differential Revision: https://phabricator.services.mozilla.com/D231083
Asserting in the ctor does not really help with anything, as the construction of this object can be the result of very asynchronously happening IPC messages such that we cannot guarantee anything from the sender's side about the receiver's state.
But we can avoid to do the heavy and hang prone work of CollectProcessInfo during shutdown.
Differential Revision: https://phabricator.services.mozilla.com/D245938
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
This implements the crash helper service used to move child process crash
report generation out of the main process and into its own process. This is
implemented as a separate executable that is launched on startup by the main
process on the desktop platforms and as a service hosted by a separate process
on Android.
The crash helper process is started when the first exception handler is set
on desktop platforms and before loading libxul on Android. In both cases
starting this process happens asynchronously so that neither the main process
nor child processes have to wait for it to come up. If a crash happens before
the crash helper has started, the crashed process will wait for it to fully
come up and then proceed with regular crash generation.
IPC with the crash helper is implemented using Unix sockets on Linux and macOS
with the former using sequential packets and the latter using stream sockets.
On Windows we use named pipes. In all cases the choice of IPC was dictated both
by the requirement to eventually talk directly to child processes from within
the sandbox, and to external processes in case of Windows as the Windows
Error Reporting exception handler must be able to reach out to the helper from
within a restricted context. These particular requirements are not used yet but
will be as we move more logic out of the main process logic.
Differential Revision: https://phabricator.services.mozilla.com/D231083
This implements the crash helper service used to move child process crash
report generation out of the main process and into its own process. This is
implemented as a separate executable that is launched on startup by the main
process on the desktop platforms and as a service hosted by a separate process
on Android.
The crash helper process is started when the first exception handler is set
on desktop platforms and before loading libxul on Android. In both cases
starting this process happens asynchronously so that neither the main process
nor child processes have to wait for it to come up. If a crash happens before
the crash helper has started, the crashed process will wait for it to fully
come up and then proceed with regular crash generation.
IPC with the crash helper is implemented using Unix sockets on Linux and macOS
with the former using sequential packets and the latter using stream sockets.
On Windows we use named pipes. In all cases the choice of IPC was dictated both
by the requirement to eventually talk directly to child processes from within
the sandbox, and to external processes in case of Windows as the Windows
Error Reporting exception handler must be able to reach out to the helper from
within a restricted context. These particular requirements are not used yet but
will be as we move more logic out of the main process logic.
Differential Revision: https://phabricator.services.mozilla.com/D231083
In cases where Available() is called on a DecryptingInputStream in one process
and then serialized and deserialized to another process, if the underlying
stream retains its position, then the deserialized DecryptingInputStream will
be in a broken state because the serialization does not propagate the internal
state that makes the altered stream position okay.
This is because when restoring state with its final restorative Seek(), the
call to DecryptingInputStream::Seek will invoke ParseNextChunk() which will
perform a read (if possible).
This fix consists of a minor change to seek the underlying stream to its
start in EnsureBuffers which will always be called exactly once before we do
any I/O, and will only happen when we were going to do I/O anyways, so this
does not induce any I/O when it would not have happened.
This patch originally contained test changes to
dom/quota/test/gtest/TestEncryptedStream.cpp but they have now been split out
in consultation with the reviewer, :janv. Specifically the test required the
StringInputStream to serialize its offset but there is additional work to be
done for the requested XPCOM changes to correspond to that. The test changes
will land as part of that follow-up stack.
The changes were made in order to test serialization and ensure that we also
have coverage for not calling the side-effect including Available() method
prior to reads (in order to be consistent with what we see with http request
bodies when the socket process is in use). If the fix is commented out and
testing with the test, the test will fail permutations starting with
`DOM_Quota_EncryptedStream_Parametrized/ParametrizedCryptTest.DummyCipherStrategy_SerializeRoundtrip`.
In order to stick with the TestEncryptedStream.cpp GTest not using a file input
stream, DecryptingInputStream needed to have its serialization logic
generalized to support other serializable streams in the test. That change has
been retained.
Differential Revision: https://phabricator.services.mozilla.com/D241157
Bug 1942129 added a use of PR_BEGIN_MACRO to SharedMemoryPlatform_mach.cpp, but only included the macro's definition (in prtypes.h) when building for iOS, not macOS.
/Users/chris/Code/mozilla/firefox-hg/ipc/glue/SharedMemoryPlatform_mach.cpp:67:5: error: unknown type name 'PR_BEGIN_MACRO'
67 | LOG_ERROR("Failed to make memory entry (%zu bytes). %s (%x)\n", aSize,
| ^
/Users/chris/Code/mozilla/firefox-hg/ipc/glue/SharedMemoryPlatform_mach.cpp:38:5: note: expanded from macro 'LOG_ERROR'
38 | PR_BEGIN_MACRO \
| ^
Differential Revision: https://phabricator.services.mozilla.com/D242646
