This avoids some ordering issues between js export phase and mozglue generate
phase. As well, we don't really need two copies of the same file so this is
simpler.
At the same time, move the few baseprofiler headers that are not already in
mozilla/ into that directory. It seems to be a historical accident that we
ended up with the split rather than a bonified reason.
Differential Revision: https://phabricator.services.mozilla.com/D278064
It is replaced by a standard-conforming cast to (void) which is
understood the same by the compiler.
In some cases this could be replaced by `[[maybe_unused]]` but for
expression whose value is ignored, this requires storing to a temporary
variable first, so not going that way.
One notable change is that marking an object of type already_AddRefed as
unused used to implicitly leak memory. This is now made explicit.
Most of the heavy lifting was done through:
$ git grep -l '\<Unused\> <<' | xargs sed -i -e 's/Unused << /(void)/g'
$ git grep -l mozilla/Unused.h | xargs sed -i -e '/mozilla\/Unused.h/ d'
Differential Revision: https://phabricator.services.mozilla.com/D268706
It is replaced by a standard-conforming cast to (void) which is
understood the same by the compiler.
In some cases this could be replaced by `[[maybe_unused]]` but for
expression whose value is ignored, this requires storing to a temporary
variable first, so not going that way.
One notable change is that marking an object of type already_AddRefed as
unused used to implicitly leak memory. This is now made explicit.
Most of the heavy lifting was done through:
$ git grep -l '\<Unused\> <<' | xargs sed -i -e 's/Unused << /(void)/g'
$ git grep -l mozilla/Unused.h | xargs sed -i -e '/mozilla\/Unused.h/ d'
Differential Revision: https://phabricator.services.mozilla.com/D268706
It is replaced by a standard-conforming cast to (void) which is
understood the same by the compiler.
In some cases this could be replaced by `[[maybe_unused]]` but for
expression whose value is ignored, this requires storing to a temporary
variable first, so not going that way.
One notable change is that marking an object of type already_AddRefed as
unused used to implicitly leak memory. This is now made explicit.
Most of the heavy lifting was done through:
$ git grep -l '\<Unused\> <<' | xargs sed -i -e 's/Unused << /(void)/g'
$ git grep -l mozilla/Unused.h | xargs sed -i -e '/mozilla\/Unused.h/ d'
Differential Revision: https://phabricator.services.mozilla.com/D268706
It is replaced by a standard-conforming cast to (void) which is
understood the same by the compiler.
In some cases this could be replaced by `[[maybe_unused]]` but for
expression whose value is ignored, this requires storing to a temporary
variable first, so not going that way.
One notable change is that marking an object of type already_AddRefed as
unused used to implicitly leak memory. This is now made explicit.
Most of the heavy lifting was done through:
$ git grep -l '\<Unused\> <<' | xargs sed -i -e 's/Unused << /(void)/g'
$ git grep -l mozilla/Unused.h | xargs sed -i -e '/mozilla\/Unused.h/ d'
Differential Revision: https://phabricator.services.mozilla.com/D268706
See the comment in the patch for details. Chromium's version of this is
applied in the zygote after forking, and there's an argument for doing
this in the fork server now that it's enabled by default, but I think it
makes more sense in `main` after returning from the fork server hook.
I've tested this manually by using bpftrace to observe calls to
`expand_files`.
Differential Revision: https://phabricator.services.mozilla.com/D261842
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 adjusts the various places where we initialize content
processes to call SetGeckoProcessType as early as possible, and be more
consistent. After this change we should only ever set GeckoProcessType
and GeckoChildID once per-process (with the exception of the fork server
process).
In addition to this validation, some more checks around the fork server
were added, such as to prevent forking another forkserver, or forking a
non-content process.
As part of this change, there was some refactoring/cleanup done, such as
removing plugin-container.cpp and content_process_main, as compared to
the other duplicated code between the two call-sites, the duplication
was relatively small, and inlining it helped make things more readable.
Differential Revision: https://phabricator.services.mozilla.com/D218471
The new GeckoChildID type introduced in this patch is inspired by the existing
ContentParentID type used by ContentParent, but is currently distinct. It is
supported by all process types at the GeckoChildProcessHost level and can be
read for the current process from anywhere.
As this type is similar in many ways to the process type, and should be
available as early as possible within child processes, this was added alongside
the GeckoProcessType value within mozglue to make that easier to do.
The type was chosen to be an int32_t to make it feel similar to a PID, which we
currently use for process identity comparisons across the codebase. The
intention is for GeckoChildID to be preferred for these within-gecko checks, as
these IDs will not be re-used and can be known earlier during child process
creation.
Differential Revision: https://phabricator.services.mozilla.com/D217117
Reserve the lower positions of the file descriptors to make sure
we don't reuse stdin/stdout/stderr in case they we closed
before launch.
Differential Revision: https://phabricator.services.mozilla.com/D175337
BCryptGenRandom can be broken, but the Rust stdlib and the getrandom
crate rely on it, and this is a source of crashes which are Rust
panics. This happens the most on Windows 7 after bcryptprimitives.dll
fails to load (see bug 1788004).
To mitigate these crashes, we hook BCryptGenRandom if we detect that it
is broken, and install a fallback based on RtlGenRandom. We only protect
calls that use BCRYPT_USE_SYSTEM_PREFERRED_RNG; so code that relies on
using BCryptOpenAlgorithmProvider and doesn't have its own fallback can
still fail.
We will hopefully remove this hook when the Rust stdlib and the
getrandom crate both have their own RtlGenRandom-based fallback.
Differential Revision: https://phabricator.services.mozilla.com/D170662
As with the socket process, we can't automated test that the block works in the GPU process, but I manually verified this. I did add an automated test that ensures blocking something in the GPU process doesn't block it in other processes.
Differential Revision: https://phabricator.services.mozilla.com/D167399
As with the socket process, we can't automated test that the block works in the GPU process, but I manually verified this. I did add an automated test that ensures blocking something in the GPU process doesn't block it in other processes.
Differential Revision: https://phabricator.services.mozilla.com/D167399
This is a refactoring that makes SharedSection::Reset() do the resolving of Kernel32ExportsSolver. This will allow us in a future patch to let the SharedSection attempt to resolve Kernel32ExportsSolver multiple times, as it will fail if kernel32.dll isn't loaded in the process yet, but we still want to initialize the dynamic blocklist in that case.
Differential Revision: https://phabricator.services.mozilla.com/D164486
This is a refactoring that makes SharedSection::Reset() do the resolving of Kernel32ExportsSolver. This will allow us in a future patch to let the SharedSection attempt to resolve Kernel32ExportsSolver multiple times, as it will fail if kernel32.dll isn't loaded in the process yet, but we still want to initialize the dynamic blocklist in that case.
Differential Revision: https://phabricator.services.mozilla.com/D164486
This is a refactoring that makes SharedSection::Reset() do the resolving of Kernel32ExportsSolver. This will allow us in a future patch to let the SharedSection attempt to resolve Kernel32ExportsSolver multiple times, as it will fail if kernel32.dll isn't loaded in the process yet, but we still want to initialize the dynamic blocklist in that case.
Differential Revision: https://phabricator.services.mozilla.com/D164486
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