1746232 - RDD process is restarted after crashes without throttling

Status: RESOLVED DUPLICATE of bug 1761942

(Core :: Audio/Video, defect, P3)

Description

[Jed Davis [:jld] ⟨⏰|UTC-8⟩ ⟦he/him⟧]

Noticed with bug 1743928: when the RDD process crashes, depending on the nature of the crash, it's immediately restarted without throttling, which can lead to a crash loop and very large numbers of crash reports.

My STR is:

1. undo the fix for bug 1743928
2. change the initializer for FFmpegVideoDecoder::mUseDMABufSurfaces to true
3. turn on media.ffmpeg.vaapi.enabled
4. load VP8/VP9 video (like this) with an amdgpu device (which doesn't have hardware support for those codecs, causing fallback to software)

If I don't do step 3, I get a different crash (the same ioctl, but used via libgbm instead of directly by our code) and that one doesn't loop.

The stack for the crash that loops is (edited for clarity):

#03: SyncDmaBuf (widget/gtk/DMABufSurface.cpp:670)
#04: DMABufSurface::MapInternal (widget/gtk/DMABufSurface.cpp:712)
#05: DMABufSurfaceYUV::UpdateYUVData (widget/gtk/DMABufSurface.cpp:995)
#06: DMABufSurfaceYUV::CreateYUVSurface (widget/gtk/DMABufSurface.cpp:842)
#07: mozilla::VideoFramePool::GetVideoFrameSurface (dom/media/platforms/ffmpeg/FFmpegVideoFramePool.cpp:138)
#08: mozilla::FFmpegVideoDecoder<46465650>::CreateImageDMABuf (dom/media/platforms/ffmpeg/FFmpegVideoDecoder.cpp:767)
#09: mozilla::FFmpegVideoDecoder<46465650>::DoDecode 
(dom/media/platforms/ffmpeg/FFmpegVideoDecoder.cpp:499)
#11: mozilla::FFmpegDataDecoder<46465650>::ProcessDecode (dom/media/platforms/ffmpeg/FFmpegDataDecoder.cpp:139)

The crash that doesn't loop is:

#02: gbm_bo_create (/lib/x86_64-linux-gnu/libgbm.so.1 + 0x3cc5)
#03: mozilla::widget::nsGbmLib::Create (widget/gtk/DMABufLibWrapper.h:68)
#04: DMABufSurfaceYUV::CreateYUVPlane (widget/gtk/DMABufSurface.cpp:944)
#05: DMABufSurfaceYUV::Create (widget/gtk/DMABufSurface.cpp:1022)
#06: DMABufSurfaceYUV::CreateYUVSurface (widget/gtk/DMABufSurface.cpp:842)
#07: mozilla::VideoFramePool::GetVideoFrameSurface (dom/media/platforms/ffmpeg/FFmpegVideoFramePool.cpp:138)
#08: mozilla::FFmpegVideoDecoder<46465650>::CreateImageDMABuf (dom/media/platforms/ffmpeg/FFmpegVideoDecoder.cpp:767)
#09: mozilla::FFmpegVideoDecoder<46465650>::DoDecode (dom/media/platforms/ffmpeg/FFmpegVideoDecoder.cpp:499)
#11: mozilla::FFmpegDataDecoder<46465650>::ProcessDecode (dom/media/platforms/ffmpeg/FFmpegDataDecoder.cpp:139)

Both of them happen when the <video> element is first displayed (i.e., not playing yet, just a still frame preview).

Comment 1

[Martin Stránský [:stransky] (ni? me)]

I think when we crash with VA-API we should restart RDD without HW acceleration (Bug 1752493).

Comment 2

[Martin Stránský [:stransky] (ni? me)]

Can be reproduced with calling undefined functions from decoder - for instance add av_buffer_get_ref_count(mFrame->buf[0]) to FFmpegVideoDecoder<LIBAV_VER>::CreateImage().

Comment 3

[Gian-Carlo Pascutto [:gcp]]

I think it makes more sense to have this as S2 maybe rather than bug 1749324. I'll up it for now, we can reconsider later.

Comment 4

[Martin Stránský [:stransky] (ni? me)]

Seems to be fixed now by Bug 1752493.

Comment 5

[Martin Stránský [:stransky] (ni? me)]

Correct dupe is Bug 1761942. There's a also a difference how quickly is RDD restarted. There's some timeout on Nightly but we restart RDD ASAP on release.