Maybe Fission related. (DOMFissionEnabled=1)

Crash report: https://crash-stats.mozilla.org/report/index/739ecad8-900c-4eda-8432-437d80210107

Reason: SIGSYS

Top 10 frames of crashing thread:

0 libc.so.6 __ioctl 
1 libdrm.so.2 <name omitted> ../xf86drm.c:191
2 libdrm.so.2 <name omitted> ../xf86drm.c:843
3 libva-drm.so.2 <name omitted> va_drm.c:64
4 libva.so.2 <name omitted> va.c:724
5 libxul.so mozilla::FFmpegVideoDecoder<46465650>::CreateVAAPIDeviceContext dom/media/platforms/ffmpeg/FFmpegVideoDecoder.cpp:246
6 libxul.so mozilla::FFmpegVideoDecoder<46465650>::InitVAAPIDecoder dom/media/platforms/ffmpeg/FFmpegVideoDecoder.cpp:285
7 libxul.so mozilla::FFmpegVideoDecoder<46465650>::Init dom/media/platforms/ffmpeg/FFmpegVideoDecoder.cpp:382
8 libxul.so mozilla::detail::ProxyFunctionRunnable<mozilla::MediaDataDecoderProxy::Init xpcom/threads/MozPromise.h:1630
9 libxul.so mozilla::TaskQueue::Runner::Run xpcom/threads/TaskQueue.cpp:158

I have a gazillion of these crashes, but on a clean profile it seems to work, so something is clearly off somewhere?

The only other media prefs I have modified are the eme/gmp ones (but I checked that on a clean profile they also don't make a difference), and media.videocontrols.picture-in-picture.video-toggle.has-used (which shouldn't be related)

Also, this is a very recent regression

Guess this might have been from bug 1681043? There's about 2k crashes on last build, 0 on the one before. I guess before we weren't using hardware decoding anyways?

But I can't figure out why it doesn't happen on a regular profile... I don't have any rdd pref with non-default values or anything, so I'm very confused... why are we creating an ffmpeg decoder in the rdd process? media.rdd-ffmpeg.enabled is false here...

Jean-Yves, do you know what might be going on? I know you're no longer working for MoCo, so feel free to just clear out the ni? if you want (thanks for all the awesome work you've done, btw!)...

(In reply to Emilio Cobos Álvarez (:emilio) from comment #4)

Guess this might have been from bug 1681043? There's about 2k crashes on last build, 0 on the one before. I guess before we weren't using hardware decoding anyways?

But I can't figure out why it doesn't happen on a regular profile... I don't have any rdd pref with non-default values or anything, so I'm very confused... why are we creating an ffmpeg decoder in the rdd process? media.rdd-ffmpeg.enabled is false here...

It seems that it's attempting to load the VA libraries; which can't work in the RDD process.

I'm not sure why it's trying to do that; vaapi should be disabled by default.
Here to decide if VAAPI is enabled; all it does is check if globally VAAPI is enabled and if the compositor if WR
That logic seems wrong to me, it doesn't cater for running outside the content process.

https://searchfox.org/mozilla-central/rev/ef900cd2258d4c5d968093f612f807d96e6e7c98/dom/media/platforms/ffmpeg/FFmpegVideoDecoder.cpp#366-369

The best fix for this will be with bug 1683808;in the mean time this code should check if we are in the RDD process and if the sandbox is enabled it disable things accordingly.

The crash can only occur if "media.ffmpeg.vaapi.enabled" preference is set to true; that's not its default.

Another way to fix the crash would be to do like we do on windows here:
https://searchfox.org/mozilla-central/rev/ef900cd2258d4c5d968093f612f807d96e6e7c98/dom/media/ipc/RDDParent.cpp#169-199

If the RDD crashed once; it would disabled HW decoding ; we should do the same on linux, so that widget::GetDMABufDevice()->IsDMABufVAAPIEnabled() returns false if aCreateHardwareDevice was set to false.

We will have a single crash; the RDD will be restarted which will be transparent to the user:

I'm going to see if I can fix it tonight.

Please note that I'm on holiday, and no longer a mozilla employee. So if things aren't fixed quickly enough, please take the bug.

Right, my point was that on a clean profile, with just the vaapi pref enabled, stuff doesn't crash, sorry, should've clarified.

Disable for now until bug 1683808 is properly fixed.

Set release status flags based on info from the regressing bug 1681043

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

I no longer have access to crash stats. Can someone verify that there's no crashes following this change?

Thanks.

The build ID for the latest Nightly is 20210107213748 that is later than the build ID 20210107040715 which is the last seen in the crash report. So far, after landing you patches, I didn't see any new crash.