Omnijar::Init can detect corrupted zip files and react accordingly. It
cannot fail if omni.ja is just missing, as we might run in a
configuration where resources are loaded directly from the modules
directory. We thus add also a canary load of the AppConstants
module to XRE_mainRun as soon as we have a JS context.
Differential Revision: https://phabricator.services.mozilla.com/D205026
This adds a pref to disable jit compilation by calling JS::DisableJitBackend in
the parent process. This will be used on iOS, where the jit entitlements are
only available for sandboxed content processes.
Differential Revision: https://phabricator.services.mozilla.com/D203498
This adds a pref to disable jit compilation by calling JS::DisableJitBackend in
the parent process. This will be used on iOS, where the jit entitlements are
only available for sandboxed content processes.
Differential Revision: https://phabricator.services.mozilla.com/D203498
Looking at bug 1877605 made me realize we should define better when (startup) prefs
are set exactly.
This patch adds assertions to check startup prefs can only be set before `JS_Init` and
also fixes the embeddings to follow this new rule. This makes the JS shell and browser
behavior more consistent, and makes it possible to rely on pref values during startup.
Differential Revision: https://phabricator.services.mozilla.com/D200148
When looking pernos debug session, since `nsLayoutStatics` isn't destroyed,
`nsLanguageAtomService` isn't destroyed. It seems to be some objects are
leaked according to stdout and stderr on debug build.
So we should destroy this service to avoid other debug assertion even if
`nsLayoutStatics` isn't destroyed.
Differential Revision: https://phabricator.services.mozilla.com/D192607
This has been on Nightly for several cycles without serious problems, I think
it makes sense to let it ride the trains, and continue to keep an eye on
crash reports.
Differential Revision: https://phabricator.services.mozilla.com/D191892
This change adds the PHCManager class which observes a pref to control PHC.
The pref can be changed at runtime and will affect the parent and content
processes.
Differential Revision: https://phabricator.services.mozilla.com/D178754
This change adds the PHCManager class which observes a pref to control PHC.
The pref can be changed at runtime and will affect the parent and content
processes.
Differential Revision: https://phabricator.services.mozilla.com/D178754
We're seeing inconsistent handling of OOMs in the ICU library. This
patch changes the behaviour to crash on OOM rather than allowing
ICU to handle the allocation failure. The inconsistent handling in ICU
could lead to ICU being in an inconsistent state which could in turn
cause security problems. The safer alternative is to crash, but it's
possible this will lead to too high of crash rate. For now, we'll try
this on Nightly only and monitor crash reports to see what impact this
change has.
Differential Revision: https://phabricator.services.mozilla.com/D186226
Currently, each content process re-derives the path(s) of the omnijar
file(s). We used to pass it down as a command-line argument, but
those args were also accepted by the parent process and there were
issues with that (CVE-2020-6799) such that they were completely removed
(bug 1531475). However, content processes can generally trust their
arguments; note that they currently accept `-appDir`.
We were already using `-gredir` for this on Android (it has a unified
omnijar, so there's no `-appdir` in that case); this patch subsumes the
content-process case of that, but not the parent process (which consumes
basically a fake argv constructed in Java code).
Note that only the parent process and content processes use the
omnijars; every other process type uses either minimal XPCOM, which
doesn't include them, or no XPCOM at all (e.g., GMP before bug 1845946).
The end goal of this patch series is to use those flags with the fork
server (so that it can preload the files without needing any XPCOM), but
this patch changes only the case of content processes.
Differential Revision: https://phabricator.services.mozilla.com/D182510
Some debug infrastructure like MOZ_WEAKPTR_INIT_THREAD_SAFETY_CHECK that can apparently be triggered by nsComponentManagerImpl::gComponentManager->FreeService() seem to rely on the existence of a serial event target even if they do not post any events. So it seems sound to keep a representation of the main thread as nsThread object until after final XPCOM shutdown.
But nsThreadManager::ShutdownMainThread() does more, it processes the last round of events, removes the thread's observer and closes down the background event target. We do not want to move these operations to happen later than before, such that we split the nsThread release into a separate function and move that together with AbstractThread::ShutdownMainThread() behind FreeService().
Depends on D160628
Differential Revision: https://phabricator.services.mozilla.com/D162497
Some debug infrastructure like MOZ_WEAKPTR_INIT_THREAD_SAFETY_CHECK that can apparently be triggered by nsComponentManagerImpl::gComponentManager->FreeService() seem to rely on the existence of a serial event target even if they do not post any events. So it seems sound to keep a representation of the main thread as nsThread object until after final XPCOM shutdown.
But nsThreadManager::ShutdownMainThread() does more, it processes the last round of events, removes the thread's observer and closes down the background event target. We do not want to move these operations to happen later than before, such that we split the nsThread release into a separate function and move that together with AbstractThread::ShutdownMainThread() behind FreeService().
Depends on D160628
Differential Revision: https://phabricator.services.mozilla.com/D162497
`gXPCOMThreadsShutDown` is needed for the assertion in `ThreadEventTarget::Dispatch` but we do not want other shutdown checks to rely on it, as it is too specific for this case. If we ever would really need this checkpoint in time during runtime in release we should consider to make it become a new `ShutdownPhase` in between.
We move the state to `ThreadEventTarget` and have a `DEBUG` only method to prime that assertion over there.
Differential Revision: https://phabricator.services.mozilla.com/D160627