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)
(deleted),
text/x-phabricator-request
|
Details |
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]
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
|
||
Comment 11•2 years ago
|
||
bugherder |
Description
•