Gnome Xwayland, Debian Testing, Intel Iris Graphics 6100 (BDW GT3) (0x8086 0x162b Mesa 21.2.5.0)

Tab crash on Twitter while playing a video.

Maybe Fission related. (DOMFissionEnabled=1)

Crash report: https://crash-stats.mozilla.org/report/index/b2b09184-19c1-40de-b2a5-9c4fc0211130

Reason: SIGSYS

Top 4 frames of crashing thread:

0 libc.so.6 semget sysdeps/unix/sysv/linux/semget.c:31
1 iHD_drv_video.so OsContextSpecific::CreateIPC obj-x86_64-linux-gnu/media_driver/media_driver/linux/common/os/mos_context_specific.cpp:285
2 iHD_drv_video.so OsContextSpecific::Init 
3 iHD_drv_video.so DdiMedia_InitMediaContext 

Maybe Fission related. (DOMFissionEnabled=1)

Crash report: https://crash-stats.mozilla.org/report/index/14b66965-1dbb-4408-b431-9369f0211130

MOZ_CRASH Reason: MOZ_DIAGNOSTIC_ASSERT(!IsUsed())

Top 10 frames of crashing thread:

0 libxul.so mozilla::VideoFrameSurfaceVAAPI::ReleaseVAAPIData dom/media/platforms/ffmpeg/FFmpegVideoFramePool.cpp:59
1 libxul.so mozilla::VideoFramePool::GetVideoFrameSurface dom/media/platforms/ffmpeg/FFmpegVideoFramePool.cpp:115
2 libxul.so mozilla::FFmpegVideoDecoder<58>::CreateImageVAAPI dom/media/platforms/ffmpeg/FFmpegVideoDecoder.cpp:728
3 libxul.so mozilla::FFmpegVideoDecoder<58>::DoDecode dom/media/platforms/ffmpeg/FFmpegVideoDecoder.cpp:491
4 libxul.so mozilla::FFmpegDataDecoder<58>::DoDecode dom/media/platforms/ffmpeg/FFmpegDataDecoder.cpp:182
5 libxul.so mozilla::FFmpegDataDecoder<58>::ProcessDecode dom/media/platforms/ffmpeg/FFmpegDataDecoder.cpp:138
6 libxul.so mozilla::detail::ProxyRunnable<mozilla::MozPromise<nsTArray<RefPtr<mozilla::MediaData> >, mozilla::MediaResult, true>, RefPtr<mozilla::MozPromise<nsTArray<RefPtr<mozilla::MediaData> >, mozilla::MediaResult, true> >  xpcom/threads/MozPromise.h:1536
7 libxul.so mozilla::TaskQueue::Runner::Run xpcom/threads/TaskQueue.cpp:208
8 libxul.so nsThreadPool::Run xpcom/threads/nsThreadPool.cpp:305
9 libxul.so NS_ProcessNextEvent xpcom/threads/nsThreadUtils.cpp:467

bp-14b66965-1dbb-4408-b431-9369f0211130 30.11.21, 01:26 [@ mozilla::VideoFrameSurfaceVAAPI::ReleaseVAAPIData ]
bp-b2b09184-19c1-40de-b2a5-9c4fc0211130 30.11.21, 01:26 [@ semget ]

I assume the rdd crash occured first ([@ mozilla::VideoFrameSurfaceVAAPI::ReleaseVAAPIData ])
and then VAAPI was tried in the content process and failed ([@ semget ]).

Can VAAPI be made forbidden for the content process?

Filed bug 1743647 for semget (content process).

Jan, can you reproduce the ReleaseVAAPIData crash reliably? If so, can you provide MOZ_LOG="Dmabuf:5, PlatformDecoderModule:5" log?
Thanks.

We'd need to run ./mach mochitest dom/media/test with vaapi / dmabuf enabled to test that somehow.

Make VideoFramePool thread safe to avoid multiple access during software decode to DMABuf:

• Create Mutex for VideoFramePool access
• Hide VideoFrameSurfaceDMABuf / VideoFrameSurfaceVAAPI and provide only abstract VideoFrameSurface class to video decoder.
• Mark surface as used when it's provided by VideoFramePool to avoid race conditions.

(In reply to Martin Stránský [:stransky] (ni? me) from comment #4)

Jan, can you reproduce the ReleaseVAAPIData crash reliably?

No, last time so far was 2021-12-16 (bp-2c5b4ad0-eb9f-4aa9-a2ab-4dc060211216).

Okay, I guess we need the thread safe surface pool anyway.

https://hg.mozilla.org/mozilla-central/rev/c9dcc854039a

Since the status are different for nightly and release, what's the status for beta?
For more information, please visit auto_nag documentation.