1418831 - Crash in mozilla::layers::AutoLockD3D11Texture::AutoLockD3D11Texture

Status: RESOLVED WORKSFORME

(Core :: Graphics, defect, P2)

Description

[[:philipp]]

This bug was filed from the Socorro interface and is
report bp-6c2142fc-3aeb-42c9-88ab-c79890171119.
=============================================================

Top 10 frames of crashing thread:

0 xul.dll mozilla::layers::AutoLockD3D11Texture::AutoLockD3D11Texture gfx/layers/d3d11/TextureD3D11.cpp:1842
1 xul.dll mozilla::layers::D3D11YCbCrImage::SetData gfx/layers/D3D11YCbCrImage.cpp:98
2 xul.dll mozilla::VideoData::CreateAndCopyData dom/media/MediaData.cpp:330
3 xul.dll mozilla::FFmpegVideoDecoder<46465650>::DoDecode dom/media/platforms/ffmpeg/FFmpegVideoDecoder.cpp:337
4 xul.dll mozilla::FFmpegDataDecoder<46465650>::DoDecode dom/media/platforms/ffmpeg/FFmpegDataDecoder.cpp:159
5 xul.dll mozilla::FFmpegDataDecoder<46465650>::ProcessDecode dom/media/platforms/ffmpeg/FFmpegDataDecoder.cpp:127
6 xul.dll mozilla::detail::ProxyRunnable<mozilla::MozPromise<nsTArray<RefPtr<mozilla::MediaData> >, mozilla::MediaResult, 1>, RefPtr<mozilla::MozPromise<nsTArray<RefPtr<mozilla::MediaData> >, mozilla::MediaResult, 1> >  xpcom/threads/MozPromise.h:1395
7 xul.dll mozilla::TaskQueue::Runner::Run xpcom/threads/TaskQueue.cpp:246
8 xul.dll nsThreadPool::Run xpcom/threads/nsThreadPool.cpp:228
9 xul.dll nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:1037

=============================================================

these are content crashes starting since firefox 56 with MOZ_CRASH("GFX: IMFYCbCrImage timeout"); that got added in bug 1223270.
the volume seems to be rising at the start of the 58.0b cycle, ob 58.0b4 it's the #15 top content crash.

Comment 1

[Blake Wu [:bwu][:blakewu]]

Jya,
I belive this is your bug. :-)

Comment 2

[Kilik Kuo [:kikuo] (inactive)]

There's a GraphicsCriticalError "|[C0][GFX1-]: LayerManager::EndTransaction skip RenderLayer(). (t=605111) " in one of the crash  metadata [1].

Does handling the device reset like here [2] instead of making it crash help ?

[1] https://crash-stats.mozilla.com/report/index/53bbc2e7-e7ba-4294-8d94-53fac0171120#tab-metadata
[2] https://searchfox.org/mozilla-central/rev/9d920555ec81f1c9d4b7fa3b08e23eb88efb60e1/gfx/layers/d3d11/TextureD3D11.cpp#1804-1809

Comment 3

[Jean-Yves Avenard [:jya]]

why not..

This is a MOZ_CRASH however, shouldn't crash unless you're in a debug build though.

Comment 4

[Milan Sreckovic [:milan] (needinfo for best results)]

Actually, MOZ_CRASH does take down the release build as well.

Comment 5

[Jean-Yves Avenard [:jya]]

Matt, you were the original author of this code in bug 1138967 (I only moved out to a global scope).

Should we crash like now, ignore the timeout, increase the wait time?

Comment 6

[Matt Woodrow (:mattwoodrow)]

(In reply to Jean-Yves Avenard [:jya] from comment #5)
> Matt, you were the original author of this code in bug 1138967 (I only moved
> out to a global scope).
> 
> Should we crash like now, ignore the timeout, increase the wait time?

We're already waiting 10 seconds, that's a pretty long time.

Can we just return a failed result back to the caller, and try a different texture type?

Comment 7

[Ryan VanderMeulen [:RyanVM]]

This is still lingering around with a pretty high crash rate on release (500+ in the last week in 60.0.2). Is there anything actionable we can do here?

Comment 8

[Jean-Yves Avenard [:jya]]

This really is more a gfx issue than media... It's outside my realm of expertise.

:Bas , any ideas?

Comment 9

[Liz Henry (:lizzard) (relman/hg->git project)]

David, can you help find someone to investigate? There are only a few crashes for beta 62 but the volume on release is pretty high.

Comment 10

[David Bolter [:davidb] (NeedInfo me for attention)]

Thanks for the ping, Bas said he'd take a look.

Comment 11

[Pascal Chevrel:pascalc]

Bas, could you give an update on this bug? We still have about 40 crashes a day across channels. Thanks

Comment 12

[Bas Schouten (:bas.schouten)]

(In reply to Pascal Chevrel:pascalc from comment #11)
> Bas, could you give an update on this bug? We still have about 40 crashes a
> day across channels. Thanks

I'm not on the graphics team anymore. Looking at the bug, and the patch that seems to have caused it. This seems like it probably just needs us to extend the timeout time. Or we're somehow not dealing with a device reset here correctly. I'm not sure what Jean-Yves patch did that could have increased the crash rate here, but maybe we're trying to reuse textures that are still locked by something else?

Comment 13

[Hani Yacoub, Desktop QA]

Closing this as resolved:worksforme since there were no crashes in the last 6 months for this signature.

Comment 14

[Hani Yacoub, Desktop QA]

I'll Reopen this bug again. There have been crashes with this signature.

Comment 15

[Wayne Mery (:wsmwk)]

(In reply to Hani Yacoub from comment #14)

I'll Reopen this bug again. There have been crashes with this signature.

All version 78-ish and older, fwiw