Closed Bug 1684474 Opened 4 years ago Closed 1 year ago

Crash in [@ mozilla::layers::SyncObjectD3D11Host::Synchronize]

Categories

(Core :: Graphics, defect)

x86_64
Windows 10
defect

Tracking

()

RESOLVED WONTFIX

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

Keywords: crash

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Component: General → PDF Viewer
Component: PDF Viewer → Untriaged

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.

Component: Untriaged → Graphics
Product: Firefox → Core

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].

Seems to have something to do with texture management. Low volume crash in the old layers system. Probably not actionable.

Severity: -- → S4
Flags: needinfo?(nical.bugzilla)

Sotaro might have an idea, but yeah the crash volume is too low to worry prioritize at this point.

Flags: needinfo?(nical.bugzilla) → needinfo?(sotaro.ikeda.g)

(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.

Flags: needinfo?(sotaro.ikeda.g)
Flags: needinfo?(sotaro.ikeda.g)
Version: Firefox 85 → unspecified

(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.

(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

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

(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?

The bug has a crash signature, thus the bug will be considered confirmed.

Status: UNCONFIRMED → NEW
Ever confirmed: true

Closing because no crashes reported for 12 weeks.

Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → WORKSFORME
Resolution: WORKSFORME → WONTFIX
You need to log in before you can comment on or make changes to this bug.