Crash report: https://crash-stats.mozilla.org/report/index/548e8c78-3b33-44e4-8857-c85bb0201021

Reason: SIGSYS

Top 10 frames of crashing thread:

0 libc.so.6 __getdents64 /usr/src/debug/glibc-2.32/dirent/../sysdeps/unix/sysv/linux/getdents64.c:32
1 libc.so.6 __readdir64 /usr/src/debug/glibc-2.32/dirent/../sysdeps/posix/readdir.c:65
2 libc.so.6 __get_nprocs_conf /usr/src/debug/glibc-2.32/misc/../sysdeps/unix/sysv/linux/getsysstats.c:248
3 libc.so.6 __sysconf /usr/src/debug/glibc-2.32/posix/../sysdeps/unix/sysv/linux/x86/sysconf.c:36
4 libnspr4.so PR_GetNumberOfProcessors nsprpub/pr/src/misc/prsystem.c:254
5 libxul.so mozilla::FFmpegVideoDecoder<46465650>::InitCodecContext dom/media/platforms/ffmpeg/FFmpegVideoDecoder.cpp:415
6 libxul.so mozilla::FFmpegDataDecoder<46465650>::InitDecoder dom/media/platforms/ffmpeg/FFmpegDataDecoder.cpp:96
7 libxul.so mozilla::FFmpegVideoDecoder<46465650>::Init dom/media/platforms/ffmpeg/FFmpegVideoDecoder.cpp:385
8 libxul.so mozilla::detail::ProxyFunctionRunnable<mozilla::MediaDataDecoderProxy::Init xpcom/threads/MozPromise.h:1564
9 libxul.so mozilla::TaskQueue::Runner::Run xpcom/threads/TaskQueue.cpp:158

I think since it takes an FD this might be ok, but let me know if this
somehow doesn't cut it and a more nuanced fix is needed.

Since stuff like PR_GetNumberOfProcessors() uses it with some glibc
versions, which is pretty basic functionality, we probably need to make
it work in all processes.

BTW, this can't happen with default preferences value.

(In reply to Jean-Yves Avenard [:jya] from comment #3)

BTW, this can't happen with default preferences value.

This was totally happening on a default profile with MOZ_ENABLE_WAYLAND=1, what am I missing?

I bisected this to https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=2a46f29c8cdd6f6269483e86c6e21e649ffa7127&tochange=4c3e6fb95aa6184651f215d466e702ff7d1660d3, with no other prefs rather than the wayland setting.

This is the top crash on the 10/21 Linux nightlies, with 74%(!!!) of all crashes.

Why don't we land this patch?

Having said that, while a crash will be reported by the crash reporter, it will not crash the browser nor the tab.

It will just fall-back to decoding in content.

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

(In reply to Jean-Yves Avenard [:jya] from comment #3)

BTW, this can't happen with default preferences value.

This was totally happening on a default profile with MOZ_ENABLE_WAYLAND=1, what am I missing?

Yes my bad. I got confused by your comment that it was happening when playing h264. But that's not the case, it's the vp9 decoder that is crashing. We query the number of CPU to set how many threads can be use by the decoder.

What is surprising, is how come those wasn't caught by our auto test coverage, it would have hit that code all the time.

I tested on Ubuntu and I see no such crashes.

From Jed's comment it sounds like this will need followups.

(In reply to Jean-Yves Avenard [:jya] from comment #8)

What is surprising, is how come those wasn't caught by our auto test coverage, it would have hit that code all the time.

Looks like PR_GetNumberOfProcessors first tries to parse /sys/devices/system/cpu/present, and if that doesn't work falls back to sysconf( _SC_NPROCESSORS_CONF ). The latter then counts the number of cpu* subdirectories of /sys/devices/system/cpu which is what calls readdir. I guess we don't have to fall back in automation?

https://hg.mozilla.org/mozilla-central/rev/1c7244c1d3b5