For things that can be parsed as Javascript, we need to figure out
if they are JSON, and we want to block opaque JSON resources for ORB.
This initial version just checks the first byte of the response, and
blocks it if it's a curly bracket.
Differential Revision: https://phabricator.services.mozilla.com/D163283
This is intended to be used to mark messages which do nothing on the
receiving side other than setting up state for future IPC messages,
meaning that the send can be delayed until other more important work is
complete, or until a non-LazySend IPC message is sent.
This does not break any message ordering guarantees, as the lazy
messages will be sent in order before any non-lazy messages are sent.
Differential Revision: https://phabricator.services.mozilla.com/D164274
On the build types where child processes need to go through full
shutdown to write some kind of logs or data (debug / refcount logging,
sanitizers, code coverage), the parent process currently waits forever
for them to exit and blocks its own shutdown to do so. If we were to
time out and kill the child processes, test runs would fail due to
missing the log files they were expected to write; instead, they fail
and blame the parent process for not exiting, which is not especially
helpful.
What we'd like is to know the state of the child process that's failing
to exit. This patch attempts to get a crash report in that situation; on
Unix we send SIGABRT, and on Windows we inject a thread that calls
DbgBreakPoint, both of which result in invoking our crash reporter.
Differential Revision: https://phabricator.services.mozilla.com/D161098
This is required for deserializing nsIPrincipal instances from PrincipalInfo to
be threadsafe, as setting domain with `SetDomain()` is only safe on the main
thread, due to it enumerating and updating JS wrappers.
Differential Revision: https://phabricator.services.mozilla.com/D163036
This is done using the gtest framework, and adds a new protocol which has its
messages counted. As the IPDLUnitTest process doesn't count IPC messages with
glean, this only counts messages on the parent process side.
This test also checks that we don't count this information outside of nightly,
and that it isn't counted for messages sent within the same process.
Differential Revision: https://phabricator.services.mozilla.com/D158275
This will provide us with more information with which to discover what
IPC messages are being sent extremely frequently, especially from
background processes, and what we can do to avoid unnecessary wakeups.
This is intended for power usage work, and is being tracked in a similar
way to the thread wakeups work, based on process types, such that the
data can be compared between the two.
Differential Revision: https://phabricator.services.mozilla.com/D157855
This introduces a new type to ContentParent which acts as a weak handle to the
actor and is safe to hold and manipulate from any thread.
This replaces accesses of the `ContentParent` type from the background thread,
as they were error-prone due to ContentParent not being threadsafe-refcounted.
The bulk of this patch is piping the new type through to the places it is
required, and removing now-unecessary extra complexity.
Differential Revision: https://phabricator.services.mozilla.com/D162346
This is done using slightly different mechanisms for each of LoadInfo and
nsDocShellLoadState, and will be used in the next part to validate document
loads based on the RemoteType responsible for the load.
For subresource loads, the TriggeringRemoteType is fairly straightforward - it
is the process which created the channel. We can handle this by getting the
current remote type when creating the channel, and then using the remote type
of the sending process when receiving the LoadInfo over IPC to either replace
the triggering remote type, or validate it.
For document loads, the situation is a bit more complex, as there are at least
3 (potentially-)different processes responsible for different parts of the
navigation:
1. The "Triggering Process" is the process which provided the URI to load.
This is also the process which provides the Triggering Principal. This is
the process being tracked in this patch.
2. The "Loading Process" is the process which actually creates the channel and
starts the load. This may be the same as the triggering process, or may be
a different process starting the navigation on behalf of the triggering
process. In general this is the process hosting the current docshell,
though it may be the parent process in the case of parent-initiated loads.
3. The "Final Process" is the process which receives the response and renders
the final document. This isn't known at channel creation time, and is
determined by the result principal and process isolation policy.
This change uses a serializer and special field on nsDocShellLoadState to track
the "Triggering Process" for the load, even as the load state is serialized
between processes by tracking which loads were sent into which content
processes, and matching them up when the parent process sees them again. The
information is then copied into the LoadInfo before configuring the real
channel, so it can be used for security checks.
The "Triggering Process" is overridden to be the parent process for history
loads, as history loads are often started in processes which wouldn't normally
be able to navigate to those pages. This is OK thanks to the changes in part 1
which validate history loads against the real session history when SHIP is
enabled.
Differential Revision: https://phabricator.services.mozilla.com/D161198
Using ipc::Shmem causes unbounded shmem use growth until e.g. a Worker
yields to the event loop. If a Worker never yields, Shmems sent to WebGLParent
are never released.
Specifically the manager (PCanvasManager) for WebGLParent calls
DestroySharedMemory, which sends/enqueues for WebGLChild's manager a
matching call to ShmemDestroyed. However, while WebGLChild refuses to spin its
event loop (such as a no-return WASM Worker), the ShmemDestroyed events
will just pile up. Closing e.g. the tab frees the shmems, but they accumulate
unbounded until the Worker yields to the event loop.
This is true for other users of ipc::Shmem (or RaiiShmem) as well, but
entrypoints other than DispatchCommands are rarer and can be handled
later similarly.
Differential Revision: https://phabricator.services.mozilla.com/D162946
Using ipc::Shmem causes unbounded shmem use growth until e.g. a Worker
yields to the event loop. If a Worker never yields, Shmems sent to WebGLParent
are never released.
Specifically the manager (PCanvasManager) for WebGLParent calls
DestroySharedMemory, which sends/enqueues for WebGLChild's manager a
matching call to ShmemDestroyed. However, while WebGLChild refuses to spin its
event loop (such as a no-return WASM Worker), the ShmemDestroyed events
will just pile up. Closing e.g. the tab frees the shmems, but they accumulate
unbounded until the Worker yields to the event loop.
This is true for other users of ipc::Shmem (or RaiiShmem) as well, but
entrypoints other than DispatchCommands are rarer and can be handled
later similarly.
Differential Revision: https://phabricator.services.mozilla.com/D162946
Instead of relying on OS.File.setCurrentDirectory in the xpcshell test harness
we instead provide a function to directly change directory.
Differential Revision: https://phabricator.services.mozilla.com/D148977
In profiles of the regressing benchmarks, it appears that there is some amount
of locking contention when large numbers of small messages messages over IPC.
While the bulk of this contention is probably caused by the OnIOCompleted
callbacks on the IO thread, there's not much we can do about those wake-ups.
This patch tries to reduce the contention by avoiding acquiring the mutex when
receiving IPC messages using the ChannelCapability introduced in part 1.
I am hopeful that this will slightly improve performance, however it seems
likely that there will still be slowdowns due to other parts (like NtWriteFile)
not being easy to optimize.
Future changes such as using a shared memory ring buffer for IPC on windows, or
an approach like ipcz which uses shared memory to avoid signalling messages in
some situations, may improve performance here in the future.
Differential Revision: https://phabricator.services.mozilla.com/D161855
This patch introduces a new combined capability, ChannelCapability, which
combines the previous Mutex and IOThread capabilities into a single common
capability. This capability can be asserted using the `Note` methods when
holding the specific inner capabilities to either allow shared access to
guarded variables while holding a single capability, or exclusive access when
holding all capabilities.
This is similar to the MutexSingleWriter pattern, however this implementation
is more flexible, as it also allows interacting with each individual inner
capability individually.
This patch just migrates existing attributes and mutex accesses to their new
names. Changes to behaviour will happen in part 2.
Differential Revision: https://phabricator.services.mozilla.com/D160532
This is done using the gtest framework, and adds a new protocol which has its
messages counted. As the IPDLUnitTest process doesn't count IPC messages with
glean, this only counts messages on the parent process side.
This test also checks that we don't count this information outside of nightly,
and that it isn't counted for messages sent within the same process.
Differential Revision: https://phabricator.services.mozilla.com/D158275
This will provide us with more information with which to discover what
IPC messages are being sent extremely frequently, especially from
background processes, and what we can do to avoid unnecessary wakeups.
This is intended for power usage work, and is being tracked in a similar
way to the thread wakeups work, based on process types, such that the
data can be compared between the two.
Differential Revision: https://phabricator.services.mozilla.com/D157855
Add a few relevant caveats to ObjectWatcher documentation, in the hope
of keeping someone else from following it down to a dead end.
Differential Revision: https://phabricator.services.mozilla.com/D159561
This is done using the gtest framework, and adds a new protocol which has its
messages counted. As the IPDLUnitTest process doesn't count IPC messages with
glean, this only counts messages on the parent process side.
This test also checks that we don't count this information outside of nightly,
and that it isn't counted for messages sent within the same process.
Differential Revision: https://phabricator.services.mozilla.com/D158275
This will provide us with more information with which to discover what
IPC messages are being sent extremely frequently, especially from
background processes, and what we can do to avoid unnecessary wakeups.
This is intended for power usage work, and is being tracked in a similar
way to the thread wakeups work, based on process types, such that the
data can be compared between the two.
Differential Revision: https://phabricator.services.mozilla.com/D157855
This is less of lie and avoids calling Mapped() twice. Once during
SharedMemoryBasic::Create and once during SharedMemoryBasic::Map.
This fixes shmem-mapped giving the appearence of leaking because
of the double counting.
Differential Revision: https://phabricator.services.mozilla.com/D160990
It seems RHEntryInfoToRHEntry may sometimes fail because deserializing the
principal fails. However, in this case `NS_ENSURE_SUCCESS(rv, rv);` does
nothing and is probably just a left-over from a refactoring.
If we don't bail early we may wind up with a nullptr in the redirectHistory
chain, which is most unexpected.
Differential Revision: https://phabricator.services.mozilla.com/D159373
This is an adaptation of an improvement that landed upstream in Chromium
(https://crbug.com/869154), to assert that `GetProcessId` doesn't fail
with an invalid handle error; it apparently helped them track down some
use-after-close bugs, so it might be useful. There are two changes:
1. The assertion is enabled only if `MOZ_DIAGNOSTIC_ASSERT` would be.
2. This patch allows both `kInvalidProcessHandle` as well as null
handles to simply fail, rather than passing them to the OS and
setting off the assertion. Upstream uses only nullptr for optional
handles (and we should too, but that's beyond the scope of this
patch).
Differential Revision: https://phabricator.services.mozilla.com/D160297
It is possible to specify full names for capabilities when using the clang
thread-safety analysis which will be used in error messages. We should use that
form of the attribute rather than the legacy lockable attribute.
Differential Revision: https://phabricator.services.mozilla.com/D160531
This patch is effectively two upstream fixes to `base::GetProcId` on Windows:
1. Removing the fallback to NtQueryInformationProcess, which we haven't
needed since I think 2012, and which was thread-unsafe; this could have
resulted in spurious failures if two threads raced to be the first call
to the function.
2. No longer calling DuplicateHandle to get the `PROCESS_QUERY_INFORMATION`
access right; the process handles that we open should already have it.
Bug 1794200 has links to Chromium's code reviews for these changes.
Differential Revision: https://phabricator.services.mozilla.com/D160296
ProcessWatcher takes ownership of the handle and may close it
immediately if the process has already exited, so that needs to
happen last; currently, because GetProcessId returns 0 for errors,
DeregisterChildCrashAnnotationFileDescriptor will be passed 0 in that
case, and will silently fail and leak resources.
Differential Revision: https://phabricator.services.mozilla.com/D160295
OpenBSD, uniquely (as far as I know) of our Unix targets, doesn't
support the function `waitid`, which means that the fix for bug 1793523
broke the build. However, OpenBSD isn't affected by bug 1793523 because
the crash reporter isn't supported, so it can continue to use `waitpid`.
This patch restores the `waitpid` version of `IsProcessDead` under an
ifdef. I've tested it locally on Linux (by changing the ifdef), and as
expected it does exhibit bug 1793523 but otherwise seems to work, so it
should work on OpenBSD.
Differential Revision: https://phabricator.services.mozilla.com/D160113
The PTest protocols are only built for the C++ unit tests, which we
never want to build as part of a regular build.
The PPlugin protocols were removed along with NPAPI.
PLayerTransaction was removed at some point.
For the PDocAccessible messages I removed, I added logging to
checkFixedSyncMessages to make it print out everything in "fixed",
and I manually checked the dozen or so messages to see if there
were any messages with that name in .ipdl files in the tree. The
ones I removed aren't present.
Differential Revision: https://phabricator.services.mozilla.com/D159653
When IPC is waiting for a process to exit at the same time the crash
reporter is trying to attach to the main thread with `ptrace`, both of
them will use `waitpid` for their respective state changes, and these
calls can race: the ptrace-stop is delivered to IPC, while the crash
reporter and crashed child process hang forever.
This patch changes IPC to use `waitid` with `WNOWAIT`, which allows us to
check the process status without side-effecting it; if it is an exit, the
call is reissued without that flag to obtain the status as before.
(This may not be a problem on macOS, where we use Mach APIs instead of
`ptrace`, but `waitid` has been in POSIX long enough that we should be
safe using it on all Unix platforms.)
This patch also adds some logging when child processes exit with a
failure status or due to a signal.
Differential Revision: https://phabricator.services.mozilla.com/D159186
Bug 1277705 removed most of the callers of the IPC helper function
DidProcessCrash. Currently the only use is on Unix (so the Windows
implementation is dead) and only to check if the process exited; the
return value (i.e., did the process crash) is ignored.
To simplify things for the next patch, this patch removes the unused
functionality and leaves a Unix-only IsProcessDead (the name of the
wrapper that was previously the only call site).
No functional change is intended.
Differential Revision: https://phabricator.services.mozilla.com/D159185
The IPC code that deals with waiting for child processes to exit has some
special cases that happen only if the processes take some time to exit.
Currently we're not making any attempt to run that code at all; this
patch attempts to fix that, although it doesn't do anything to verify
that any particular behavior (other than the absence of crashes) happens
in those cases.
Specifically, if the build has tests enabled, the environment variable
`MOZ_TEST_CHILD_EXIT_HANG` now introduces an artificial delay on child
process exit (in a different place for debug vs. opt builds; see
comments for details), and a test case has been added that runs content
processes with that env var set.
Differential Revision: https://phabricator.services.mozilla.com/D159184
We didn't close gfxconfig and the device manager properly before, which
causes a leak.
Also, using `mKind` to store the kind in the beginning helps us not need
to call `UtilityProcessChild::GetSingleton()` again to check the type,
which would also cause leaking and that would be addressed in bug 1792952.
Depends on D158072
Differential Revision: https://phabricator.services.mozilla.com/D158386
Now that SetGeckoProcessType() is called earlier, we can use that to determine if we are a utility process instead of parsing command-line arguments
Differential Revision: https://phabricator.services.mozilla.com/D158811
This involves some changes to IPC::Channel::ChannelImpl on all platforms in
order to ensure that they are threadsafe.
1. The ChannelImpl is now internally refcounted, making the correctness
of parts of its lifecycle more clear.
2. Members of the channel are all annotated with `MOZ_GUARDED_BY` for either
the `io_thread_` or `mutex_` depending on if they are required in order to
send a message. This gives us some static checks that we won't deadlock.
3. The `closed_` field is removed, as thanks to the mutex, `pipe_` can now be
checked directly from any thread instead. This reduces the risk of
forgetting to update `closed_`.
4. `NodeChannel` now calls `Send()` without dispatching, which also required
updating some other members to also be accessible from any thread, including
changes to allow asynchronously reporting a channel error when `Send()`
fails.
5. The Windows handling for `Connect()` was made more thread-safe to queue
calls to `Send()` performed before `Connect()` returns. The posix
`Connect()` handler already did this.
Differential Revision: https://phabricator.services.mozilla.com/D158162
Previously the channel used by the ForkServer would be created using
IPC::Channel, and then stolen after the launch was successful. Unfortunately,
this required invoking IPC::Channel methods (such as `Close()`) from the wrong
thread, and so would be racy and hit assertions with the new checks being
added. This patch instead skips creating the IPC::Channel for the fork server,
and allows it to create and configure its own pipe as needed.
This may be used in the future to change out the IPC strategy for the fork
server to something more appropriate, which supports features like async
replies as forked processes die.
Differential Revision: https://phabricator.services.mozilla.com/D158161
Greg Stoll
Marco Castelluccio
Randell Jesup
Jed Davis
Sandor Molnar
Cosmin Sabou
Gabriele Svelto
Norisz Fay
Marian-Vasile Laza
Sean Feng
Yulia Startsev
Nika Layzell
Csoregi Natalia
Andrew McCreight
Paul Zuehlcke
Jan Varga
Chris Martin
Sebastian Hengst
Adrien Champion
Manuel Bucher
Cristian Tuns
Alexandre Lissy
Otto Länd
Kelsey Gilbert
Magnus Melin
Noemi Erli
Barret Rennie
Dana Keeler
Butkovits Atila
Nicolas Silva
Kagami Sascha Rosylight
ahochheiden
Iulian Moraru
Ray Kraesig
Jeff Muizelaar
Bobby Holley
Stanca Serban
Jens Stutte
Valentin Gosu
Mark Banner
Benjamin VanderSloot
Henri Sivonen
alwu