These macros will produce better outputs when they fail than these existing
patterns using `ENSURE_TRUE(NS_SUCCEEDED(...))` or similar, so this is a bulk
rewrite of existing tests to use them.
It should also help with discoverability when people base their tests off of
other existing tests.
Differential Revision: https://phabricator.services.mozilla.com/D157214
This patch moves the media engine from the RDD process to the new
utility process, and create video bridge between the new utility process
and the GPU process in order to share the texture.
Differential Revision: https://phabricator.services.mozilla.com/D155901
Create a new type of utility process which would be used for media
foundation media engine CDM usage. The media engine is a media pipeline
provided by the Windows Media Foundation, and our final goal is to use
that pipeline to play encrypted content in order to achieve Widevine L1
protection to allow users to watch high resolution videos.
Differential Revision: https://phabricator.services.mozilla.com/D154033
The child actor will be held by FileSystemManager on the child side and the
parent actor already holds FileSystemDataManager, so it makes sense to rename
the protocol to PFileSystemManager.
Differential Revision: https://phabricator.services.mozilla.com/D155368
PBackgroundFileSystem currently contains only one async message and we don't
plan to add more messages, so the one and only message can be defined directly
on PBackground.
Differential Revision: https://phabricator.services.mozilla.com/D155367
Due to Shmem implementing ParamTraits, it is possible for a Shmem argument to
not be visible to the IPDL compiler as it is only serialized within an opaque
type included with `using`. If that happens, it would cause the construction of
the Shmem to fail on the other side, in a hard to diagnose manner. This changes
the logic to always allow any actor to manage shmems, to make it more in line
with the `AllocShmem` method being directly declared on IProtocol.
This specifically caused issues after this patch stack with PContent, which no
longer has any shmem arguments visible to IPDL after these changes, but still
is used as a manager for Shmems included in some messages.
Differential Revision: https://phabricator.services.mozilla.com/D151855
In code-coverage builds we have code which, after `fork` in the child
process, does a number of async-signal-unsafe operations which aren't
permitted in that context. In particular, locking is a problem: if
another thread in the parent process had held the lock, it will deadlock.
Most of this is conditional on the `GCOV_CHILD_PREFIX` env var being
set, and currently we don't (see bug 1724239), but checking that env var
itself is a problem, because `PR_GetEnv` takes a mutex. (This was found
by inspection, so I don't know if it's happening in practice, but it's
possible that mysterious timeouts on ccov builds might be caused by this
bug.)
Therefore, this patch moves reading the env var into the parent process,
where it's safe; the rest of the code still contains unsafe operations
(although our `pthread_atfork` hooks in mozjemalloc might help) but it
won't be run.
This will need further cleanup at some point; see bug 1783305.
Differential Revision: https://phabricator.services.mozilla.com/D154572
Due to Shmem implementing ParamTraits, it is possible for a Shmem argument to
not be visible to the IPDL compiler as it is only serialized within an opaque
type included with `using`. If that happens, it would cause the construction of
the Shmem to fail on the other side, in a hard to diagnose manner. This changes
the logic to always allow any actor to manage shmems, to make it more in line
with the `AllocShmem` method being directly declared on IProtocol.
This specifically caused issues after this patch stack with PContent, which no
longer has any shmem arguments visible to IPDL after these changes, but still
is used as a manager for Shmems included in some messages.
Differential Revision: https://phabricator.services.mozilla.com/D151855
Most users of JSONWriter want to fill a string, so instead of having all these
similar implementations, we now have central reusable implementations:
- JSONStringWriteFunc contains a string and writes to it.
- JSONStringRefWriteFunc references a string and writes to it. This is most
useful when the string already exists somewhere, or needs to be returned from
a function (so we avoid another conversion when returning).
Differential Revision: https://phabricator.services.mozilla.com/D154618
mWriter is never null (and lots of calls just dereference it without checking),
so we may as well enforce it:
- The constructor MOZ_RELEASE_ASSERTs that it's not null.
- The accessor WriteFunc() returns a reference instead of a scary raw pointer.
(Note that we can't make mWriter a NotNull<...>, because the next patch will
give the option to keep that owning pointer null.)
Differential Revision: https://phabricator.services.mozilla.com/D154616
Most users of JSONWriter want to fill a string, so instead of having all these
similar implementations, we now have central reusable implementations:
- JSONStringWriteFunc contains a string and writes to it.
- JSONStringRefWriteFunc references a string and writes to it. This is most
useful when the string already exists somewhere, or needs to be returned from
a function (so we avoid another conversion when returning).
Depends on D154617
Differential Revision: https://phabricator.services.mozilla.com/D154618
mWriter is never null (and lots of calls just dereference it without checking),
so we may as well enforce it:
- The constructor MOZ_RELEASE_ASSERTs that it's not null.
- The accessor WriteFunc() returns a reference instead of a scary raw pointer.
(Note that we can't make mWriter a NotNull<...>, because the next patch will
give the option to keep that owning pointer null.)
Differential Revision: https://phabricator.services.mozilla.com/D154616
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
The function DidProcessCrash is now dead code. Before the ProcessWatcher
rewrite, its return value (i.e., whether the process crashed) was never
used, so effectively its only purpose was to make it harder to understand
where the waitpid calls were happening.
Differential Revision: https://phabricator.services.mozilla.com/D141310
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 won't be used for any security or routing purposes, but can be useful for
debugging. It will be used in the future by the profiler to correlate sent and
received message events across processes.
Differential Revision: https://phabricator.services.mozilla.com/D153621
These constructors are unnecessary and can be defined with a `using` statement,
making it easier to change all constructors simultaneously.
Differential Revision: https://phabricator.services.mozilla.com/D153620
This improves consistency with the child process case, and will make it easier
to attach additional state without needing to thread it through every child
process callsite manually.
Differential Revision: https://phabricator.services.mozilla.com/D153619
This type is also used in other places to start non-initial actors, and will
allow us to attach additional state more easily without needing to thread it
through every child process callsite manually.
Differential Revision: https://phabricator.services.mozilla.com/D153618
Previously this code read the atomic rather than the cached value (which
was unused). This is inherently racy as the atomic is updated on a
different thread than the read happened on.
Differential Revision: https://phabricator.services.mozilla.com/D153617
Currently, Subprocess.jsm on Unix uses js-ctypes to call `posix_spawn`.
This has some issues, primarily that file descriptors are inherited by
the child process unless explicitly opted-out, which unfortunately a lot
of code doesn't do. This patch changes it to use IPC process launching,
where fd inheritance is opt-in, by:
1. Extending `base::LaunchApp` to handle a few features that Subprocess
needs (setting the process's working directory, specifying the full
environment, and the macOS `disclaim` flag)
2. Adding a WebIDL method to `IOUtils` to expose that function to JS
(currently Unix-only; Windows could also be supported but it would
probably want to use a different IDL type for strings, given that the
OS APIs use 16-bit code units).
3. Replacing the part of Subprocess that invokes `posix_spawn` (and
related functions) by calling that method; the rest of Subprocess's
machinery to manage pipes and I/O is unchanged. (The Windows backend
is also unchanged; I'm not aware of any functional issues there.)
This results in some dead code, which is removed.
Differential Revision: https://phabricator.services.mozilla.com/D152336
