Crash in [@ mozilla::layers::SyncObjectD3D11Host::Synchronize]
Categories
(Core :: Graphics, defect)
Tracking
()
People
(Reporter: worcester12345, Unassigned, NeedInfo)
References
Details
(Keywords: crash)
Crash Data
Crash report: https://crash-stats.mozilla.org/report/index/44686f5c-249b-4f6e-a1cd-587cc0201229
MOZ_CRASH Reason: MOZ_CRASH(GFX: D3D11 normal status timeout)
Top 10 frames of crashing thread:
0 xul.dll mozilla::layers::SyncObjectD3D11Host::Synchronize gfx/layers/d3d11/TextureD3D11.cpp:1639
1 xul.dll mozilla::layers::CompositorD3D11::BeginFrame gfx/layers/d3d11/CompositorD3D11.cpp:1233
2 xul.dll mozilla::layers::CompositorD3D11::BeginFrameForWindow gfx/layers/d3d11/CompositorD3D11.cpp:1113
3 xul.dll mozilla::layers::LayerManagerComposite::EndTransaction gfx/layers/composite/LayerManagerComposite.cpp:582
4 xul.dll mozilla::layers::CompositorBridgeParent::CompositeToTarget gfx/layers/ipc/CompositorBridgeParent.cpp:985
5 xul.dll mozilla::layers::CompositorVsyncScheduler::Composite gfx/layers/ipc/CompositorVsyncScheduler.cpp:256
6 xul.dll mozilla::detail::RunnableMethodImpl<mozilla::dom::WorkerListener*, void xpcom/threads/nsThreadUtils.h:1201
7 xul.dll nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:1200
8 xul.dll mozilla::ipc::MessagePumpForNonMainThreads::Run ipc/glue/MessagePump.cpp:302
9 xul.dll MessageLoop::RunHandler ipc/chromium/src/base/message_loop.cc:327
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:85.0) Gecko/20100101 Firefox/85.0 ID:20201220193140
Adblock Plus - free ad blocker 3.10.1
Amazon Assistant 10.2009.18.12123
Amazon Smile Redirect 2.0.11
Amazon.com 1.3
Auto Tab Discard 0.3.7
Avast Online Security 20.2.501 [DISABLED]
Bing 1.3
DuckDuckGo 1.1
Duplicate Tabs Closer 3.5.3 [DISABLED]
Google 1.1
Nightly Tester Tools 4.0
NoScript 11.1.7
Print Selection to PDF 0.1.0 [DISABLED]
Screengrab! 2.18 [DISABLED]
SortTabs 1.1.0 [DISABLED]
Tab Counter 0.4.1
Tabliss 2.0.3 [DISABLED]
Tabs manager 1.8
Wikipedia (en) 1.1
eBay 1.2
Comment 1•4 years ago
|
||
Bugbug thinks this bug should belong to this component, but please revert this change in case of error.
Updated•4 years ago
|
Comment 2•4 years ago
|
||
I will set a component to have a starting point from this. Please feel free to change it if this is not the correct component.
Reporter | ||
Comment 3•4 years ago
|
||
Unrelated, I know, but I saw "Bing 1.3" in the extensions list I posted above. I don't want that, so went to uninstall it, but it is not there. Odd. Any links to fix this are appreciated. Also now seeing DuckDuckGo 1.1, Google 1.1, and Wikipedia (en) 1.1.
Was able to remove the now unnessary Screengrab! 2.18 [DISABLED].
Updated•4 years ago
|
Comment 4•4 years ago
|
||
Seems to have something to do with texture management. Low volume crash in the old layers system. Probably not actionable.
Comment 5•4 years ago
|
||
Sotaro might have an idea, but yeah the crash volume is too low to worry prioritize at this point.
Comment 6•4 years ago
|
||
(In reply to Nicolas Silva [:nical] from comment #5)
Sotaro might have an idea, but yeah the crash volume is too low to worry prioritize at this point.
By Bug 1679577(firefox 85), advanced layer usage was disabled by default. Then CompositorD3D11 became used more on windows. But usage of LayerManagerComposite is going to be reduced by increase of WebRender usage.
And crash volume is very low. Then we could wait to see a volume of the crash.
Updated•4 years ago
|
Updated•4 years ago
|
Reporter | ||
Updated•4 years ago
|
Reporter | ||
Comment 9•3 years ago
|
||
(In reply to Jim Mathies [:jimm] from comment #4)
Seems to have something to do with texture management. Low volume crash in the old layers system. Probably not actionable.
Was it ever verified that this was a problem in "layers system"?
(In reply to Sotaro Ikeda [:sotaro] from comment #6)
(In reply to Nicolas Silva [:nical] from comment #5)
Sotaro might have an idea, but yeah the crash volume is too low to worry prioritize at this point.
By Bug 1679577(firefox 85), advanced layer usage was disabled by default. Then CompositorD3D11 became used more on windows. But usage of LayerManagerComposite is going to be reduced by increase of WebRender usage.
And crash volume is very low. Then we could wait to see a volume of the crash.
I recently read something about the end of the "layers system". Is this true? How might that affect this bug?
Still a crash that has no solution to date, so I guess it needs to stay open.
Reporter | ||
Comment 10•3 years ago
|
||
(In reply to Worcester12345 from comment #9)
(In reply to Jim Mathies [:jimm] from comment #4)
Seems to have something to do with texture management. Low volume crash in the old layers system. Probably not actionable.
Was it ever verified that this was a problem in "layers system"?
(In reply to Sotaro Ikeda [:sotaro] from comment #6)
(In reply to Nicolas Silva [:nical] from comment #5)
Sotaro might have an idea, but yeah the crash volume is too low to worry prioritize at this point.
By Bug 1679577(firefox 85), advanced layer usage was disabled by default. Then CompositorD3D11 became used more on windows. But usage of LayerManagerComposite is going to be reduced by increase of WebRender usage.
And crash volume is very low. Then we could wait to see a volume of the crash.
I recently read something about the end of the "layers system". Is this true? How might that affect this bug?
Here is the bug about "layers system" that made me put the above questions:
https://bugzilla.mozilla.org/show_bug.cgi?id=1724935
Comment 11•3 years ago
|
||
It reduces SyncObjectD3D11Host::Synchronize() usage.
SyncObjectD3D11Host::Synchronize() is called to wait content side rendering with GPU to be completed on Windows.
It was mainly used for waiting rendering completed with Direct2D in content process.
It happened with LayerManagerMLGPU and "LayerManagerComposite + CompositorD3D11".
They are not used now on gecko. gecko always uses WebRender for rendering.
WebRender does rendering in GPU process on Windows.
Then SyncObjectD3D11Host::Synchronize() normally does nothing.
And then old layer system was already removed from gecko by Bug 1724935.
system with WebRender is like the following.
https://github.com/sotaroikeda/firefox-diagrams/blob/master/gfx/gfx_PWebRenderBridge_62.pdf
Then the crash seemed to be reduced with WebRender.
But there is still a use case that SyncObjectD3D11Host::Synchronize() is necessary like Bug 1612665.
SyncObjectD3D11Host::Synchronize() is still called when it is necessary with WebRender.
https://searchfox.org/mozilla-central/rev/0ec81de2037cb0a0701d5d316f42763230b3a142/gfx/webrender_bindings/RenderCompositorANGLE.cpp#506
Reporter | ||
Comment 12•3 years ago
|
||
(In reply to Sotaro Ikeda [:sotaro] from comment #11)
It reduces SyncObjectD3D11Host::Synchronize() usage.
...
But there is still a use case that SyncObjectD3D11Host::Synchronize() is necessary like Bug 1612665.
SyncObjectD3D11Host::Synchronize() is still called when it is necessary with WebRender.
https://searchfox.org/mozilla-central/rev/0ec81de2037cb0a0701d5d316f42763230b3a142/gfx/webrender_bindings/RenderCompositorANGLE.cpp#506
So then what?
Comment 13•2 years ago
|
||
The bug has a crash signature, thus the bug will be considered confirmed.
Comment 14•1 year ago
|
||
Closing because no crashes reported for 12 weeks.
Reporter | ||
Updated•1 year ago
|
Description
•