Crash in [@ XDisplayString]: Consider blocking vdpau_drv_video.so from being loaded
Categories
(Core :: Widget: Gtk, defect)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox-esr91 | --- | unaffected |
| firefox-esr102 | --- | unaffected |
| firefox102 | --- | unaffected |
| firefox103 | --- | disabled |
| firefox104 | --- | fixed |
People
(Reporter: aryx, Assigned: rmader)
References
(Blocks 1 open bug)
Details
(Keywords: crash)
Crash Data
Attachments
(1 file)
This signature started to frequent with Firefox 103.0a1 on 20220627, Arch is most affected.
Crash report: https://crash-stats.mozilla.org/report/index/3ac6f424-a9bc-41ba-86da-169590220704
Reason: SIGSEGV / SEGV_MAPERR
Top 10 frames of crashing thread:
0 libX11.so.6 XDisplayString
1 vdpau_drv_video.so __vaDriverInit_1_13
2 libva.so.2 va_infoMessage
3 libva.so.2 vaInitialize
4 libxul.so mozilla::FFmpegVideoDecoder<46465650>::CreateVAAPIDeviceContext dom/media/platforms/ffmpeg/FFmpegVideoDecoder.cpp:222
5 libxul.so mozilla::FFmpegVideoDecoder<46465650>::InitVAAPIDecoder dom/media/platforms/ffmpeg/FFmpegVideoDecoder.cpp:286
6 libxul.so mozilla::FFmpegVideoDecoder<46465650>::Init dom/media/platforms/ffmpeg/FFmpegVideoDecoder.cpp:421
7 libxul.so mozilla::detail::ProxyFunctionRunnable<mozilla::MediaDataDecoderProxy::Init xpcom/threads/MozPromise.h:1645
8 libxul.so mozilla::TaskQueue::Runner::Run xpcom/threads/TaskQueue.cpp:259
9 libxul.so nsThreadPool::Run xpcom/threads/nsThreadPool.cpp:310
|
||
Comment 1•2 years ago
|
||
This can occur if a user force-enables VAAPI with a broken VAAPI driver.
Possible solutions:
- Detecting vdpau_drv_video.so somehow and refuse to force-enable VAAPI
- Blocking vdpau_drv_video.so in the RRD sandbox
|
Assignee | |
Comment 2•2 years ago
|
||
Oh, so vaapitest() from bug 1758473 doesn't fail because it's done without sandbox and thus wit X11 access...damn, didn't think of that.
I wonder if we can either apply the sandbox to the test process or at least ensure there can't be any X11/Wayland connection (e.g. by setting DISPLAY and WAYLAND_DISPLAY env vars to wrong values).
|
|
Assignee | |
Comment 3•2 years ago
|
||
Oh never mind, vaapitest() did work as expected - https://crash-stats.mozilla.org/report/index/3ac6f424-a9bc-41ba-86da-169590220704#tab-annotations contains glxtest: VA-API test failed: process crashed. Please check your VA-API drivers.. So we don't properly force VAAPI off in this case.
I guess all we need is to change disable to force_disable` in https://searchfox.org/mozilla-central/source/gfx/thebes/gfxPlatformGtk.cpp#239-240
|
|
Assignee | |
Updated•2 years ago
|
|
|
Assignee | |
Comment 4•2 years ago
|
||
vaapitest() is meant to be a sanity check. If it failed there's
likely something very broken about the driver and we log gfx
warnings accordingly, allowing to debug the problem.
Ensure to force-disable VAAPI in this case but still allow users
to enable the feature in blocklisted cases.
While on it fix the user pref order - otherwise debug builds run
into an assertion when forcing on by pref.
|
|
Assignee | |
Comment 5•2 years ago
|
||
The patch affects common code paths so do a full try: https://treeherder.mozilla.org/jobs?repo=try&revision=c086415f44e42d6c0215250177673595bbe8eb80
|
||
Comment 6•2 years ago
|
||
[updating status for 104 so this can properly be marked as fixed when it lands]
Pushed by robert.mader@posteo.de: https://hg.mozilla.org/integration/autoland/rev/eae66c448e16 Force-disable VAAPI if vaapitest() failed, r=gfx-reviewers,aosmond
|
||
Comment 8•2 years ago
|
||
Backed out for causing failures at test_gfxBlacklist_Version.js
backout link: https://hg.mozilla.org/integration/autoland/rev/b8040f4090250260fab3e5dd6cb60d7f48a994a6
Failure log: https://treeherder.mozilla.org/logviewer?job_id=384039623&repo=autoland&lineNumber=3266
|
||
Comment 10•2 years ago
|
||
Pushed by robert.mader@posteo.de: https://hg.mozilla.org/integration/autoland/rev/789d9363b2be Force-disable VAAPI if vaapitest() failed, r=gfx-reviewers,aosmond
|
||
Comment 11•2 years ago
|
||
| bugherder | ||
Description
•