Crash in [@ mozilla::layers::ImageBridgeParent::RecvReadbackAsyncPluginSurface]
Categories
(Core :: Graphics: Layers, defect, P1)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr68 | --- | unaffected |
firefox71 | --- | unaffected |
firefox72 | + | verified |
firefox73 | + | verified |
People
(Reporter: pascalc, Assigned: handyman)
References
(Regression)
Details
(Keywords: crash, regression)
Crash Data
Attachments
(5 files, 1 obsolete file)
This bug is for crash report bp-9db236e3-3959-41e6-a7a5-8af210191202.
Top 10 frames of crashing thread:
0 xul.dll mozilla::layers::ImageBridgeParent::RecvReadbackAsyncPluginSurface gfx/layers/ipc/ImageBridgeParent.cpp:592
1 xul.dll mozilla::layers::PImageBridgeParent::OnMessageReceived ipc/ipdl/PImageBridgeParent.cpp:866
2 xul.dll void mozilla::ipc::MessageChannel::DispatchSyncMessage ipc/glue/MessageChannel.cpp:2177
3 xul.dll void mozilla::ipc::MessageChannel::DispatchMessage ipc/glue/MessageChannel.cpp:2126
4 xul.dll mozilla::ipc::MessageChannel::MessageTask::Run ipc/glue/MessageChannel.cpp:2003
5 xul.dll MessageLoop::DoWork ipc/chromium/src/base/message_loop.cc:523
6 xul.dll void base::MessagePumpForUI::DoRunLoop ipc/chromium/src/base/message_pump_win.cc:203
7 xul.dll base::MessagePumpWin::Run ipc/chromium/src/base/message_pump_win.h:79
8 xul.dll void MessageLoop::RunHandler ipc/chromium/src/base/message_loop.cc:308
9 xul.dll MessageLoop::Run ipc/chromium/src/base/message_loop.cc:290
We have crashes on Nightly since November 22
Updated•5 years ago
|
Comment 2•5 years ago
|
||
Crashes started in 72 in 20191121214422 . Possible regression range based on Build ID: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=76e20a306bc262843ec06d59c54416131af030cb&tochange=2c912e46295e4f8a3fa5824a7f378e06760ec7dd. Looks like Bug 1577336 is in that changeset.
Assignee | ||
Comment 3•5 years ago
|
||
Bug 1598680 comment 10 mentions that this can be reproduced occasionally with tab drag-and-drop. I haven't seen that yet but it as repro it is better than nothing.
Comment 4•5 years ago
|
||
Hi,
I have managed to reproduce the issue on latest Nightly 73.0a1 (2019-12-02), but I got a different crash signature from the description.
Here is my crash report: https://crash-stats.mozilla.org/report/index/fd2f05b2-44b8-44bd-99b9-d27450191203
Based on comment 2, I will remove the regressionwindow-wanted keyword.
Thanks.
Comment 5•5 years ago
|
||
That's the signature from bug 1600032 which is at least related.
Assignee | ||
Comment 6•5 years ago
|
||
Through some luck reproducing this in the debugger, I've narrowed this to graphics operations happening on the wrong thread. The implementation of RecvReadback.... uses gfx::Factory methods that aren't thread safe here as they pair the Compositor thread and the wrong DX device. I'm going to reimplement it to use the D3D11TextureData more directly like the rest of the Recv plugin methods there.
Updated•5 years ago
|
Comment 7•5 years ago
|
||
Fixed via backout for 72.0b4. 73+ remain affected.
https://hg.mozilla.org/releases/mozilla-beta/rev/3af5f7e1bd23
Assignee | ||
Comment 8•5 years ago
|
||
ISurfaceAllocator was introduced in bug 1272018 as a planned replacement for SurfaceAllocator. They are essentially the same interface. This patch removes SurfaceAllocator.
Assignee | ||
Comment 9•5 years ago
|
||
The only reason BufferTexture needs a LayersIPCChannel instead of the IShmemAllocator base interface is that it needs to know if the allocator is cross-process or not. Both LayersIPCChannel and ISurfaceAllocator use IsSameProcess() for this but without a common interface for it. Rather than further complicate the inheritance diagram for the layers and IPDL core classes, this patch makes BufferTexture handle both with generic code.
Depends on D56224
Assignee | ||
Comment 10•5 years ago
|
||
Currently plugin readback, which happens in a number of cases including sometimes when tabs are dragged and dropped, crashes due to failed graphics operations. One of the reasons for this is that graphics operations are happening on the Compositor thread of the compositor process but they are using incompatible DX devices from gfx::Factory. This patch properly uses the device context.
Depends on D56225
Updated•5 years ago
|
Assignee | ||
Comment 11•5 years ago
|
||
These patches fix this bug -- they will be folded into the coming replacement for the backed-out patches in bug 1577336.
Updated•5 years ago
|
Updated•5 years ago
|
Updated•5 years ago
|
Comment 12•5 years ago
|
||
Reproducible on latest Nightly 73.0a1 (Build id: 20191208213628) and Beta 72.0b3.
Verified - fixed on latest Beta 72.0b4 (Build id: 20191206183317).
Assignee | ||
Comment 13•5 years ago
|
||
CreateBGRA8DataSourceSurfaceForD3D11Texture is added to create a CPU texture with the same data as the given D3D11 texture. ReadbackTexture reads a D3D11 texture into a pre-existing CPU texture. ToPixelFormat is extended to cover DXGI_FORMAT values.
Depends on D56225
Assignee | ||
Comment 14•5 years ago
|
||
Refactor D3D11ShareHandleImage::GetAsSourceSurface to use the new utility method added in Part 3.
Depends on D57562
Updated•5 years ago
|
Assignee | ||
Comment 15•5 years ago
|
||
Use the new utility function, introduced in Part 3, to implement async plugin surface's read to CPU texture.
Depends on D57563
Updated•5 years ago
|
Comment 16•5 years ago
|
||
Comment 17•5 years ago
|
||
Backed out 5 changesets for causing webgl tests and reftests to time out.
Backout link: https://hg.mozilla.org/integration/autoland/rev/75357badfa02515afa09babc79e0e345bf9b4143
Push with failures:
Failure logs:
Comment 18•5 years ago
|
||
David, this also caused bug 1605820 based on retrigger results: https://treeherder.mozilla.org/#/jobs?repo=autoland&selectedJob=282458694&searchStr=windows%2C10%2Cx64%2Cquantumrender%2Cdebug%2Creftests%2Ctest-windows10-64-qr%2Fdebug-reftest-e10s-3%2Cr%28r3%29&tochange=27a1becd947bec022c2fb02411b4d9b57a58c2a9&fromchange=cf6aaeed22e85e4df23ede5185023b3e7dba87f7
Assignee | ||
Comment 19•5 years ago
|
||
Thanks. I've got a fix for this that is passing tests. I'll make sure it passes that one, too. The issue is that the retry command in patch 3 creates a source texture that lacks a lock, which causes the retry to abort without finishing, which causes the test to fail to complete.
Updated•5 years ago
|
Comment 20•5 years ago
|
||
Comment 21•5 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/40a8f46b2286
https://hg.mozilla.org/mozilla-central/rev/164a412c769b
https://hg.mozilla.org/mozilla-central/rev/0438a77d10b1
https://hg.mozilla.org/mozilla-central/rev/be48fa6b35ed
https://hg.mozilla.org/mozilla-central/rev/6948b162ef2e
Comment 22•5 years ago
|
||
Verified - Fixed in our latest Nightly 73.0a1 (Build id: 20200105214143) using Windows 10.
Updated•3 years ago
|
Description
•