VA_DRM_GetNumCandidates changed behaviour, therefore aborts X server in VM with QXL driver. #700
Comments
|
Do you have gstreamer-vaapi installed in your qemu VM? |
Sure I have, all lines in the backtrace with "gst-libs/gst/vaapi" are from gstreamer-vaapi.
I have only tested the versions currently in Debian stable and testing but yes, the commit 317c0fb is already contained in 2.16.0.
I reported this here, because it comes to a surprise to be able to crash the whole X server by that simple command giving a file that does not even exist. And users might even have trouble to identify that this is caused by/with gstreamer-vaapi, which might get installed just by dependencies/recommends, or the VM got upgraded from an older libva where this was a working/not-crashing setup.
Do you have details on this - as far as I see the behaviour change was in libva/VA_DRM_GetNumCandidates, so this might have happened on purpose, or by accident and might be though about again, as it was not failing before. - if (status != VA_STATUS_SUCCESS)
- return status;
+ if (status != VA_STATUS_SUCCESS || num_candidates <= 0)
+ return VA_STATUS_ERROR_UNKNOWN; |
The details are from my testing. What I've found is the issue only exists in a VM when gstreamer-vaapi is installed as I've already stated. gstreamer-vaapi is a plugin for gstreamer so no package should have a dependency on it and can be safely removed. gstreamer itself doesn't depend on it. If you can provide a test case where libva causes the crash of X without gstreamer-vaapi installed then please do because I can't find one. |
|
Thanks for looking into it.
You are right, I have not found many dependencies, there just two packages in current Debian testing, one depends, one suggests:
Following minimal test case is able to break a running X server without any gstreamer package installed:
With test-vaInitialize.c having following content: /*
gcc -O0 -g test-vaInitialize.c -lva -lva-drm -o test-vaInitialize
*/
#include <fcntl.h>
#include <va/va_drm.h>
int main()
{
int major_version, minor_version;
VADisplay va_dpy;
VAStatus status;
int fd;
fd = open ("/dev/dri/card0", O_RDWR | O_CLOEXEC);
va_dpy = vaGetDisplayDRM (fd);
status = vaInitialize (va_dpy, &major_version, &minor_version);
}I wondered how |
|
Thanks. I was able to reproduce the crash. Patching VA_DRM_GetNumCandidates() so that it returns the status it did before the 2.16.0 update should do the trick: Tested with the virtio and bochs (std) drivers in qemu. |
|
As you can see from the upstream Xorg server/driver issue it's a bug on their end. It has been known for a while but seemingly nobody had the time/interest to fix that. Most importantly on can trigger that bug even without libva. So I suggest closing this issue and checking with colleagues, companies or just nerd sniping (not it) to fix that for you ;-) |
In current Debian Testing running inside a qemu VM with the QML driver the X server can be crashed by just running
gst-play-1.0 no-such-file.avi.As far as I see
VA_DRM_GetNumCandidatesdoes compare the driver name "qxl" against a known list of driversg_driver_name_map.In my debugging this list contains "qxl" neither in libva version 2.17.0-1 (Debian Bookworm/testing)
nor in 2.10.0-1 (Debian Bullseye/stable).
In version 2.10.0
VA_DRM_GetNumCandidatesreturns VA_STATUS_ERROR_UNKNOWN (because count==0).But in version 2.17.0 it returns unconditionally VA_STATUS_SUCCESS.
It look like this got introduced with commit 317c0fb.
Therefore
va_DisplayContextGetNumCandidatesdoes not return early but does enterva_drm_authenticate/VA_DRI2Authenticatewhich finally causes the X server to hit an assertion and ends therefore.Because I guess the X server should be resistant even for such queries
I opened https://gitlab.freedesktop.org/xorg/xserver/-/issues/1534.
But libva probably want to either revert back to original behaviour of
VA_DRM_GetNumCandidates,or wants to change users of it to check for the returned num_candidates > 0 or something like this?
libva/va/drm/va_drm.c
Lines 54 to 56 in 0fa448d
The text was updated successfully, but these errors were encountered: