CompositorManagerParent::sInstance is not set in GPU process. It is necessary to send NotifyWebRenderError message.
Differential Revision: https://phabricator.services.mozilla.com/D28452
--HG--
extra : moz-landing-system : lando
NotifyWebRenderError is sent via CompositorBridgeParent/CompositorBridgeChild. It is not good, since they are re-created for each nsBaseWidget::CreateCompositorSession() call. Then there could be a case that the NotifyWebRenderError is not notified to GPUProcessManager and a crash was caused by NotifyWebRenderError message during ipc close. CompositorManagerParent/CompositorManagerChild are stable for sending NotifyWebRenderError.
Differential Revision: https://phabricator.services.mozilla.com/D27030
--HG--
extra : moz-landing-system : lando
When the compositor thread has begun shutdown, it will spin the event
loop for the main thread until the last CompositorThreadHolder reference
has been released. While spinning, new IPDL objects may be attempted to
be created which depend on the compositor thread; we should check to
ensure the compositor thread is still around before proceeding with
creation. These objects include CompositorManagerParent,
ImageBridgeParent, and VRManagerParent. Additionally there is a very
similar bug between the vsync thread and VsyncBridgeChild.
Differential Revision: https://phabricator.services.mozilla.com/D23308
This cannot actually happen in the real world because this path is specific to
when the compositor process is also the parent process, and thus is not
actually IPC. However, the fuzzer can trigger this case.
Depends on D14587
Differential Revision: https://phabricator.services.mozilla.com/D14588
--HG--
extra : moz-landing-system : lando
This exposes methods to capture a snapshot of the SharedSurfacesParent
cache for memory reporting purposes. It yields the identifiers, image
properties and references to images mapped in the cache. This will be
used by the compositor process to list everything it has mapped into its
memory space. It will also be used by the content processes / main
process to list images that specific process had mapped into the
compositor process. This will allow us to easily identify what images
remain in the compositor process, but are missing from the surface
cache.
This exposes methods to capture a snapshot of the SharedSurfacesParent
cache for memory reporting purposes. It yields the identifiers, image
properties and references to images mapped in the cache. This will be
used by the compositor process to list everything it has mapped into its
memory space. It will also be used by the content processes / main
process to list images that specific process had mapped into the
compositor process. This will allow us to easily identify what images
remain in the compositor process, but are missing from the surface
cache.
This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
This patch was generated automatically by the "modeline.py" script, available
here: https://github.com/amccreight/moz-source-tools/blob/master/modeline.py
For every file that is modified in this patch, the changes are as follows:
(1) The patch changes the file to use the exact C++ mode lines from the
Mozilla coding style guide, available here:
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#Mode_Line
(2) The patch deletes any blank lines between the mode line & the MPL
boilerplate comment.
(3) If the file previously had the mode lines and MPL boilerplate in a
single contiguous C++ comment, then the patch splits them into
separate C++ comments, to match the boilerplate in the coding style.
MozReview-Commit-ID: 77D61xpSmIl
--HG--
extra : rebase_source : c6162fa3cf539a07177a19838324bf368faa162b
This patch doesn't modify the mode lines at all -- it just swaps their order,
and makes each one its own C++ comment, separate from the MPL boilerplate
comment.
MozReview-Commit-ID: BEZJVj2sMuK
--HG--
extra : rebase_source : 9e0946c8a8d0b67c11b5932b9d1e51e0e6e8ebef
From the crashes associated with bug 1389021, we know that some
compositor thread IPDL owners are not being cleaned up properly. We do
not know which protocols are causing the problem, so we temporarily will
annotate the logs with the ownership status. This should be limited to
under a dozen instances of the protocols.
This change will be backed out after a few builds are produced with it
and we see the first crash reports with the relevant data.
From the crashes associated with bug 1389021, we know that some
compositor thread IPDL owners are not being cleaned up properly. We do
not know which protocols are causing the problem, so we temporarily will
annotate the logs with the ownership status. This should be limited to
under a dozen instances of the protocols.
This change will be backed out after a few builds are produced with it
and we see the first crash reports with the relevant data.
From the crashes associated with bug 1389021, we know that some
compositor thread IPDL owners are not being cleaned up properly. We do
not know which protocols are causing the problem, so we temporarily will
annotate the logs with the ownership status. This should be limited to
under a dozen instances of the protocols.
This change will be backed out after a few builds are produced with it
and we see the first crash reports with the relevant data.
We need to ensure the compositor thread is released but we cannot upon
freeing CompositorManagerParent to do that. This is because it needs to
live longer than the thread so that shared memory allocated with this
top level protocol can be freed after the fact. As such, just release
the thread reference after IPDL has released CompositorManagerParent.
Nika Layzell
sotaro
Andrew Osmond
Ryan Hunt
Alex Gaynor
Sylvestre Ledru
Narcis Beleuzu
Bobby Holley
Gurzau Raul
Nicolas Silva
Brian Hackett
Emilio Cobos Álvarez
Sebastian Hengst
Daniel Holbert
Coroiu Cristina
Bill McCloskey
Carsten "Tomcat" Book
Wes Kocher