This change adds the ground work to share content provided by the JS engine of
the Parent process to initialize the JS engine of other threads and Content
processes.
The singleton class xpc::SelfHostedShmem is used to wrap the logic behind
holding the memory. The memory is initialized with `InitFromParent` or
`InitFromChild`. The memory is accessible using either the `Content` or
`Handle`.
The shared memory is transfered through the command line using
`mozilla::ipc::ExportSharedJSInit` and read using
`mozilla::ipc::ImportSharedJSInit` functions. The command line is used, as we
need the shared memory to be avilable for the JS engine initialization. The
command line is composed of a single command named `-jsInit` which is followed
by the handle (on Windows) and the length of the shared content.
The memory associated with the shared memory is cleared in `ShutdownXPCOM` after
closing all threads, and shuting down the JS engine. This is necessary as we
expect the JS engine to borrow content from the shared memory.
Differential Revision: https://phabricator.services.mozilla.com/D110576
This allows the `mozilla::Queue` type to be used more easily and without
causing assertion failures, leaks, or unsafe behaviour.
Differential Revision: https://phabricator.services.mozilla.com/D112763
This warning previously fired loudly from the ports logic being added in bug
1706374 were acquired. As the warning also occasionally fires in existing code
and provides no safety guarantees, I think we should consider removing it.
Differential Revision: https://phabricator.services.mozilla.com/D112762
Win32 errors ERROR_DEVICE_HARDWARE_ERROR, ERROR_DEVICE_NOT_CONNECTED, ERROR_DISK_FULL need a mapping.
NS_ERROR_FILE_DISK_FULL is duplicate to NS_ERROR_FILE_NO_DEVICE_SPACE
Drive by: RejectJSPromise lacked some NS_ERROR_* mappings
Differential Revision: https://phabricator.services.mozilla.com/D113974
We hook several file APIs to record I/O performance data. Since TLS is not
allocated in ntdll's loader worker thread, however, if someone does a file
operation, we hit read AV because `WinIOAutoObservation` uses `nsString` and
a thread local variable.
Currently we can see this crash happens only when a DLL rule of AppLocker is
defined, but theoretically this can happen when any module loaded in a worker
thread does file operation in its entrypoint.
The proposed fix is to skip `WinIOAutoObservation` if TLS is not available.
Differential Revision: https://phabricator.services.mozilla.com/D113032
This assertion currently only happens on debug builds, but attempts to dispatch delayed runnables after we have started or finished cancelling all delayed runnables in a TaskQueue may be causing shutdown hangs.
Differential Revision: https://phabricator.services.mozilla.com/D113839
There is a chance that a timer will be cancelled by its holder after the timer thread and all of the timers have been cleaned up. Doing this can result in a hang on the mutex lock, likely because the mutex is now pointing to something else. I'm not completely familiar with the inner workings of our timers so I'm not sure what the best fix is here. I decided to follow a pattern in our threading shutdown routines and flag the timer shutdown so the timers can't attempt to cancel past a certain point where they would be shutdown anyway. This is tricky because there are timers created during XPCOM shutdown all the way up until we shutdown the timer thread. Checking for the timer thread outside of the lock could also result in a race with timer shutdown. This value is an attempt to address this without breaking timers shutdown.
Differential Revision: https://phabricator.services.mozilla.com/D113448
Currently, we use `VsyncTaskManager::DidRunTask` to change state from
`RunVsync` to `NoPendingVsync`, however, the issue is that if the vsync
starts an event loop (for instance, by using requestAnimationFrame), and
the event loop starts another input task, Firefox crashes because input
tasks don't expect the state to be `RunVsync`.
So instead of using `DidRunTask`, we start to use `WillRunTask` to fix
it.
Differential Revision: https://phabricator.services.mozilla.com/D113613
DelayedDispatch, in all current implementations, will set up a timer sync and
then Dispatch() a runnable. Since the timer is set up before the Dispatch, there
is a theoretical chance that the timer fires and dispatches a TimerEvent to the
target thread before DelayedDispatch managed to do so. When this happens the
internal DelayedDispatch runnable exits early, i.e., in practice it never runs.
The chance increases dramatically if the Dispatch() to the target in question is
tail dispatched, since the time between DelayedDispatch and the tail could be
non-trivial.
This patch removes the assert that checks that all DelayedRunnables that have
run have also been scheduled, since per the above no such guarantee exists.
Differential Revision: https://phabricator.services.mozilla.com/D112876
This will allow it to be used from UA sheets (we need static atoms there
to share UA sheets with other processes).
Depends on D113114
Differential Revision: https://phabricator.services.mozilla.com/D113115
We have seen a lot of crashes with the new vsync input alignment code
because a possible case is
1. Input event runs when there's a pending vsync (state=HasPendingVsync)
2. Input event handler starts an event loop (state=HasPendingVsync)
3. Vsync runs (state=HasPendingVsync) and crashes.
It crashes because the `DidRunTask` method for the input event doesn't
get a chance to run, which supposes to set the state to RunVsync.
Differential Revision: https://phabricator.services.mozilla.com/D112799
Edgar Chen
Nicolas B. Pierron
Paul Bone
Alexandre Lissy
Andreea Pavel
Andi-Bogdan Postelnicu
Jens Stutte
Jon Coppeard
Nika Layzell
Alexandru Michis
Valentin Gosu
Christian Holler
Toshihito Kikuchi
Jesse Schwartzentruber
Dorel Luca
kriswright
Sean Feng
Steve Fink
Bas Schouten
David Parks
Cosmin Sabou
Andreas Pehrson
Emilio Cobos Álvarez
Narcis Beleuzu
Gerald Squelart
Randell Jesup
imoraru