Crash in [@ mozilla::gfx::CriticalLogger::CrashAction] from RecordedTextureLock::PlayCanvasEvent
Categories
(Core :: Graphics: Canvas2D, defect, P3)
Tracking
()
People
(Reporter: mccr8, Unassigned)
References
Details
(Keywords: crash)
Crash Data
Crash report: https://crash-stats.mozilla.org/report/index/aaa0a378-1036-43b5-b739-63d140231213
MOZ_CRASH Reason: MOZ_CRASH(GFX_CRASH)
Top 10 frames of crashing thread:
0 xul.dll CrashStatsLogForwarder::CrashAction gfx/thebes/gfxPlatform.cpp:396
1 xul.dll mozilla::gfx::CriticalLogger::CrashAction gfx/2d/Factory.cpp:1368
2 xul.dll mozilla::gfx::Log<1, mozilla::gfx::CriticalLogger>::WriteLog gfx/2d/Logging.h:761
3 xul.dll mozilla::gfx::Log<1, mozilla::gfx::CriticalLogger>::Flush gfx/2d/Logging.h:276
4 xul.dll mozilla::gfx::Log<1, mozilla::gfx::CriticalLogger>::~Log gfx/2d/Logging.h:269
5 xul.dll RefPtr<ID3D11Device>::~RefPtr mfbt/RefPtr.h:84
5 xul.dll mozilla::layers::LockD3DTexture<ID3D11Texture2D> gfx/layers/d3d11/TextureD3D11.cpp:247
6 xul.dll mozilla::layers::D3D11TextureData::Lock gfx/layers/d3d11/TextureD3D11.cpp:331
7 xul.dll mozilla::layers::RecordedTextureLock::PlayCanvasEvent const gfx/layers/RecordedCanvasEventImpl.h:168
7 xul.dll mozilla::layers::CanvasTranslator::HandleExtensionEvent gfx/layers/ipc/CanvasTranslator.cpp:493
I was tempted to call this a regression from bug 1863914, but I see this on older versions (example: bp-a7d52746-d15d-40bf-af38-08e1b0231119) going back quite a ways. Only on Nightly, but maybe this only crashes like this on Nightly.
44 crashes with this signature in the last 6 months, and 37 of them have RecordedTextureLock::PlayCanvasEvent in the proto stack. A third of them are on 122, so maybe the rate has gone up?
|
||
Comment 1•5 months ago
|
||
Lee, are you the knowledgeable person on RecordedTextureLock::PlayCanvasEvent? If not, we'll figure it out in triage.
|
||
Comment 2•5 months ago
•
|
||
(In reply to Brad Werth [:bradwerth] from comment #1)
Lee, are you the knowledgeable person on
RecordedTextureLock::PlayCanvasEvent? If not, we'll figure it out in triage.
This looks like something Bob Owen is the one to investigate.
|
|
||
Comment 3•5 months ago
|
||
CrashReport seems to say AcquireSync is returning WAIT_TIMEOUT, leading ultimately to: gfxDevCrash(LogReason::D3DLockTimeout) << "D3D lock mutex timeout - device not removed";
Smells something like a device reset. But maybe something else is just holding the lock for a really really long time?
|
||
Comment 4•4 months ago
|
||
Looks like we haven't had any of these involving RecordedTextureLock::PlayCanvasEvent since build ID 20231221170215, so I'm guessing this was fixed by bug 1871467.
lsalzman - does that seem correct?
|
|
||
Comment 5•2 months ago
|
||
We made substantial changes to reduce the amount of locking going on as well as AcquireSync behavior changes. But the impetus did occur in bug 1871467, even though there were quite a few follow-ups.
As of bug 1871811, we no longer actually try to do an actual lock inside RecordedTextureLock, so this signature is no longer applicable. It is feasible that it might have cropped up elsewhere, but we can deal with that separately in a new bug if that is the case.
Description
•