With the new changes in bug 1724083, it is possible for an actor to be
destroyed during SetManagerAndRegister, which can lead to RemoveManagee being
called before the managee is even registered, leading to an assertion failure.
The easiest fix here is to relax this assertion, as we won't insert the entry
later in this failure case.
Differential Revision: https://phabricator.services.mozilla.com/D208936
It appears that the Element member may have been creating a reference
cycle passing through the new strong WindowGlobalParent::Manager()
reference.
This patch also removes an unused member from BrowserParent which
otherwise may have needed to be cycle-collected.
Differential Revision: https://phabricator.services.mozilla.com/D207170
There are a few IPDL actors which are cycle-collected, including `PBrowser`,
`PContent`, and `PWindowGlobal`.
This patch adds support for these actors to traverse and unlink the new strong
Manager() reference added by IPDL, allowing cycles containing these actors to
be properly unlinked and avoiding leaks.
Differential Revision: https://phabricator.services.mozilla.com/D198629
While the BackgroundChildImpl actor is not safe to use from any thread other
than the one it was created on, it holds no important thread-bound members at
destruction time, and does no meaningful work in its destructor.
Actors managed by BackgroundChild are occasionally kept alive longer than the
thread they were bound to, meaning that the new Manager() strong reference
would keep BackgroundChildImpl alive past the death of its thread and IPC link.
This change makes the reference counting threadsafe, so that it's OK to destroy
these final references from another thread.
Differential Revision: https://phabricator.services.mozilla.com/D198628
This makes accessing `Manager()` on an IPDL protocol safer, and replaces the
previous ActorLifecycleProxy reference, which would only keep the manager alive
until IPDL drops its reference.
Unfortunately this introduces some leaks due to reference cycles, which will be
fixed in follow-up parts.
Differential Revision: https://phabricator.services.mozilla.com/D198624
Suppose we have 3 nodes: A, B, and C. In this scenario A is the broker,
and there are two child-nodes B and C. A creates a port-pair (Ab <->
Ac), and sends one each to B (Ab => Bb) and C (Ac => Cc). Assuming both
directions of the proxy bypass occur concurrently, we'll send a number
of ObserveProxy messages between node A and nodes B/C, eventually
cleaning up the proxies in A, such that Bb's peer is Cc, and vice versa.
During this process, we never attempt to send a message directly between
nodes B and C.
In NodeController, direct connections between a pair of nodes are
established via the broker node when attempting to send a message
directly between nodes, but as we have not attempted to send any
messages directly, no such connection has been established. That means
that when one of these child nodes dies, the other node will not be
notified of the peer being lost, and the IPDL actor will appear to
remain open. Only once a message is sent will the death of the peer node
be discovered, and the corresponding actor destroyed.
To fix this, we modify the routing code, adding a couple of callbacks
when accepting ports over IPC and bypassing proxies which notify
NodeController, allowing it to attempt an introduction eagerly. This
helps ensure that actors will reliably be notified when their peer
processes die.
In addition, some tweaks to the introduction logic were made to both
make introductions happen reliably, and to ensure we clean up missing
peer nodes in error conditions.
Differential Revision: https://phabricator.services.mozilla.com/D201153
This changes the locking behaviour for IPC port mutexes in TSAN builds
to use a single shared mutex for all ports, rather than individual
mutexes per-port. This avoids the need to potentially lock a large
number of mutexes simultaneously when sending a large number of ports in
an IPC message.
I've tried to leave in the various debug assertions such that it still
acts like there are multiple mutexes under the hood. It is likely that
this could harm performance somewhat due to the increased contention,
however it should have no impact on actual release builds.
Differential Revision: https://phabricator.services.mozilla.com/D207073
Sorry for the massive patch but I found it hard to split without
introducing a bunch of copies around...
This mostly makes necko and DOM agree on which strings to use, which
should result on less copies and conversions.
Differential Revision: https://phabricator.services.mozilla.com/D205601
This uses BrowserEngineKit's ExtensionKit-based processes to start content
processes on iOS. These processes are started with an initial xpc connection,
which is then used to communicate a command line, initial file descriptors
and environment variables before invoking content_process_main.
The XPC connection is not used further after the bootstrap message, which seems
to roughly match how WebKit uses these APIs.
Differential Revision: https://phabricator.services.mozilla.com/D202525
If the path to your source checkout on Windows is sufficiently long enough, you
can hit the Windows maximum commandline argument limit (32k) specifying IPDL
files to ipdl.py during build. Writing the list of files to a file and passing
that to ipdl.py gets around this error completely.
Differential Revision: https://phabricator.services.mozilla.com/D204949
This removes intr support and updates some stale docs as well.
It's not immediately clear what code in MessageChannel can be removed,
though I expect some things could be simplified (there's just not much
alluding to intr/rpc/urgent).
Differential Revision: https://phabricator.services.mozilla.com/D204813
This patch checks whether child processes are in the zombie state
(`exit`ed but not `wait`ed), by parsing `/proc/{pid}/stat`, and treats
them as dead in that case.
Child processes can end up stuck in zombie state if the fork server
exits when child processes are still running, which causes them to be
reparented to pid 1, and pid 1 isn't acting as `init`, which can happen
in container environments like Docker depending on configuration. In
particular, this is currently the case in the containers used by Mozilla
CI to run tests. Without this patch, if the fork server is enabled, we
wait forever for the process to exit and then (in the Mozilla CI case)
some other timeout fires and causes the test run to fail.
Differential Revision: https://phabricator.services.mozilla.com/D204096
If the path to your source checkout on Windows is sufficiently long enough, you
can hit the Windows maximum commandline argument limit (32k) specifying IPDL
files to ipdl.py during build. Writing the list of files to a file and passing
that to ipdl.py gets around this error completely.
Differential Revision: https://phabricator.services.mozilla.com/D204949
This removes intr support and updates some stale docs as well.
It's not immediately clear what code in MessageChannel can be removed,
though I expect some things could be simplified (there's just not much
alluding to intr/rpc/urgent).
Differential Revision: https://phabricator.services.mozilla.com/D204813
This is a sync version of `nsIClipboard.asyncGetData`, which can be used for
synchronous clipboard APIs, e.g. DataTransfer, to support the clipboard seqence
number concept, see bug 1879401.
Differential Revision: https://phabricator.services.mozilla.com/D201364
Move initializing gfxVar from creating a video bridge to the moment we
create UtilityAudioDecoderParent in order to ensure that we can always
get correct value from gfxVar.
Differential Revision: https://phabricator.services.mozilla.com/D204292
Some of the assertions were changed because the message arguments are passed by const reference.
`MoveOnly` is applied to specific types, and UniquePtr is a built-in so we can't adjust that.
Differential Revision: https://phabricator.services.mozilla.com/D202263
