Xorg crashes with assertion failure at dixGetPrivateAddr: Assertion `key->initialized' failed

[linex83]

[Impact]

A very common crash in Xorg occurs when an application you are trying to launch
does not call DRI2ScreenInit() before calling DRI2Authenticate() or
DRI2CreateDrawable2().

This brings down the entire Xserver, and you lose all work.

This isn't just a single application, common ones are gstreamer1.0-vaapi
either invoked as gst-inspect-1.0 or through file manager thumbnailers,
Intel libva, and more.

The solution is to make DRI2Authenticate() and DRI2CreateDrawable2() more
robust to not having had DRI2ScreenInit() called, and to pass the error up
instead of just crashing on the assert.

Stack traces from logs:

Xorg: ../../../../../../include/privates.h:122: dixGetPrivateAddr: Assertion `key->initialized' failed.
(EE)
(EE) Backtrace:
(EE) 0: /usr/lib/xorg/Xorg (OsLookupColor+0x14c) [0x587abb9686dc]
(EE) 1: /lib/x86_64-linux-gnu/libc.so.6 (__sigaction+0x50) [0x747466445650]
(EE) 2: /lib/x86_64-linux-gnu/libc.so.6 (pthread_kill+0x11c) [0x7474664a3f5c]
(EE) 3: /lib/x86_64-linux-gnu/libc.so.6 (gsignal+0x1e) [0x74746644559e]
(EE) 4: /lib/x86_64-linux-gnu/libc.so.6 (abort+0xdf) [0x747466428902]
(EE) unw_get_proc_name failed: no unwind info found [-10]
(EE) 5: /lib/x86_64-linux-gnu/libc.so.6 (?+0x0) [0x74746642881e]
(EE) 6: /lib/x86_64-linux-gnu/libc.so.6 (__assert_fail+0x47) [0x74746643bb87]
(EE) 7: /usr/lib/xorg/Xorg (DRIMoveBuffersHelper+0xb13) [0x587abb90de23]
(EE) 8: /usr/lib/xorg/Xorg (DRI2Authenticate+0xce) [0x587abb9108de]
(EE) 9: /usr/lib/xorg/Xorg (DRI2GetParam+0x6d9) [0x587abb9116f9]
(EE) 10: /usr/lib/xorg/Xorg (SendErrorToClient+0x3fc) [0x587abb7a004c]
(EE) 11: /usr/lib/xorg/Xorg (InitFonts+0x3b3) [0x587abb7a5623]
(EE) 12: /lib/x86_64-linux-gnu/libc.so.6 (__libc_init_first+0x88) [0x74746642a3b8]
(EE) 13: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0x8b) [0x74746642a47b]
(EE) 14: /usr/lib/xorg/Xorg (_start+0x25) [0x587abb789685]
(EE)
(EE)
Fatal server error:
(EE) Caught signal 6 (Aborted). Server aborting

#0 _XReply (dpy=dpy@entry=0x55555558dce0, rep=rep@entry=0x7fffffffd6f0, extra=extra@entry=0, discard=discard@entry=0)
    at ../../src/xcb_io.c:680
#1 0x00007ffff752a3d0 in VA_DRI2Authenticate (dpy=dpy@entry=0x55555558dce0, window=1046, magic=magic@entry=1)
    at ../va/x11/va_dri2.c:225
#2 0x00007ffff7c138ed in va_drm_authenticate_x11 (fd=fd@entry=6, magic=magic@entry=1) at ../va/drm/va_drm_auth_x11.c:140
#3 0x00007ffff7c135d5 in va_drm_authenticate (fd=6, magic=1) at ../va/drm/va_drm_auth.c:37
#4 0x00007ffff7c134bd in va_DisplayContextConnect (pDisplayContext=<optimized out>) at ../va/drm/va_drm.c:62
#5 va_DisplayContextGetDriverNames (pDisplayContext=<optimized out>, drivers=0x7fffffffd890, num_drivers=0x7fffffffd884)
    at ../va/drm/va_drm.c:79
#6 0x00007ffff781729e in va_new_opendriver (dpy=0x55555558d310) at ../va/va.c:681
#7 vaInitialize
    (dpy=dpy@entry=0x55555558d310, major_version=major_version@entry=0x7fffffffdb34, minor_version=minor_version@entry=0x7fffffffdb30) at ../va/va.c:743
#8 0x00007ffff7f496d0 in vaapi_initialize (dpy=0x55555558d310) at ../gst-libs/gst/vaapi/gstvaapiutils.c:113
#9 0x00007ffff7f6db73 in supports_vaapi (fd=6) at ../gst-libs/gst/vaapi/gstvaapidisplay_drm.c:77
#10 get_default_device_path (display=0x5555555892a0 [GstVaapiDisplayDRM|vaapidisplaydrm1])
    at ../gst-libs/gst/vaapi/gstvaapidisplay_drm.c:140
#11 set_device_path (device_path=<optimized out>, display=0x5555555892a0 [GstVaapiDisplayDRM|vaapidisplaydrm1])
    at ../gst-libs/gst/vaapi/gstvaapidisplay_drm.c:181
#12 gst_vaapi_display_drm_open_display (display=0x5555555892a0 [GstVaapiDisplayDRM|vaapidisplaydrm1], name=<optimized out>)
    at ../gst-libs/gst/vaapi/gstvaapidisplay_drm.c:247
#13 0x00007ffff7f4a68b in gst_vaapi_display_create
    (data=0x0, init_type=GST_VAAPI_DISPLAY_INIT_FROM_DISPLAY_NAME, display=0x5555555892a0 [GstVaapiDisplayDRM|vaapidisplaydrm1])
    at ../gst-libs/gst/vaapi/gstvaapidisplay.c:965
#14 gst_vaapi_display_config
    (display=0x5555555892a0 [GstVaapiDisplayDRM|vaapidisplaydrm1], init_type=GST_VAAPI_DISPLAY_INIT_FROM_DISPLAY_NAME, init_value=0x0) at ../gst-libs/gst/vaapi/gstvaapidisplay.c:1272
#15 0x00007ffff7f709a1 in gst_vaapi_display_drm_new (device_path=0x0) at ../gst-libs/gst/vaapi/gstvaapidisplay_drm.c:367
#16 0x00007ffff7f0c295 in gst_vaapi_create_test_display () at ../gst/vaapi/gstvaapipluginutil.c:929
#17 plugin_init (plugin=0x555555585b10 [GstPlugin|plugin1]) at ../gst/vaapi/gstvaapi.c:191
#18 0x00007ffff7e22452 in gst_plugin_register_func
    (plugin=plugin@entry=0x555555585b10 [GstPlugin|plugin1], desc=desc@entry=0x7ffff7fb71a0 <gst_plugin_desc>, user_data=user_data@entry=0x0) at ../gst/gstplugin.c:540
#19 0x00007ffff7e279c0 in _priv_gst_plugin_load_file_for_registry
    (filename=0x55555558122c "/usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstvaapi.so", registry=<optimized out>, error=<optimized out>) at ../gst/gstplugin.c:979
#20 0x00007ffff7e6ed41 in do_plugin_load
    (tag=0, filename=0x55555558122c "/usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstvaapi.so", l=<optimized out>)
    at ../gst/gstpluginloader.c:741
#21 handle_rx_packet
    (payload_len=<optimized out>, payload=0x55555558122c "/usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstvaapi.so", tag=0, pack_type=<optimized out>, l=<optimized out>) at ../gst/gstpluginloader.c:849
#22 read_one (l=0x555555584a30) at ../gst/gstpluginloader.c:1025
#23 exchange_packets (l=l@entry=0x555555584a30) at ../gst/gstpluginloader.c:1053
#24 0x00007ffff7e703a8 in _gst_plugin_loader_client_run (pipe_name=pipe_name@entry=0x0) at ../gst/gstpluginloader.c:596
#25 0x00005555555551db in main (argc=<optimized out>, argv=<optimized out>) at ../libs/gst/helpers/gst-plugin-scanner.c:81

[Testcase]

Start a fresh VM. Make sure the session is using X Server.

$ sudo apt install gstreamer1.0-vaapi gstreamer1.0-tools
$ gst-inspect-1.0

On plucky, you don't even need to run gst-inspect-1.0, just try log in, you will
quickly find that xserver is broken and you aren't getting a X session today.

Review the backtrace in /var/log/syslog.

If you install a test package from the following ppa, the issue does not occur:

https://launchpad.net/~mruffell/+archive/ubuntu/sf392117-test

[Where problems could occur]

We are adding some protection on the xserver side against user-space applications
that incorrectly do not call DRI2ScreenInit() before attempting to construct
a window.

It would be best if all applications would call DRI2ScreenInit(), but if an
applications don't, then we need to not crash the entire xserver.

Regressions could occur in unintended behaviour for applications that can get
away without calling DRI2ScreenInit(), but those applications will likely just
continue working as usual.

If a regression were to occur, it would occur when launching applications in
Xorg desktop environments.

[Other Info]

Duplicate Bugs
--------------

At the time of writing the primary Launchpad bug has 19 duplicate bugs, which
is the most I have ever seen, so this bug impacts a large amount of people.

Upstream Bugs
-------------

https://gitlab.freedesktop.org/xorg/xserver/-/issues/1053
https://gitlab.freedesktop.org/xorg/xserver/-/issues/1340
https://gitlab.freedesktop.org/xorg/xserver/-/issues/1534
https://lists.x.org/archives/xorg-devel/2024-September/059318.html

Downstream Bugs
---------------

https://bugs.gentoo.org/841662

Merge Request and Fix
---------------------

https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1608

commit a0834009cfb10b8982a1f2b47b8ed00de254c2c3
From: Doug Brown <email address hidden>
Date: Mon, 15 Jul 2024 19:44:23 -0700
Subject: dri2: Protect against dri2ClientPrivate assertion failures
Link: https://gitlab.freedesktop.org/xorg/xserver/-/commit/a0834009cfb10b8982a1f2b47b8ed00de254c2c3

This was very recently merged.

[Ubuntu Foundations Team Bug Bot (crichton)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. It seems that your bug report is not filed about a specific source package though, rather it is just filed against Ubuntu in general. It is important that bug reports be filed about source packages so that people interested in the package can find the bugs about it. You can find some hints about determining what package your bug might be about at https://wiki.ubuntu.com/Bugs/FindRightPackage. You might also ask for help in the #ubuntu-bugs irc channel on Freenode.

To change the source package that this bug is filed about visit https://bugs.launchpad.net/ubuntu/+bug/1861609/+editstatus and add the package name in the text box next to the word Package.

[This is an automated message. I apologize if it reached you inappropriately; please just reply to this message indicating so.]

[Daniel van Vugt (vanvugt)]

Thanks for the bug report.

Normally we would ask you to always use the 'ubuntu-bug' command to open new bugs. But in this case from the attachment in comment #1 I can see this is bug 1745345.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Daniel van Vugt (vanvugt)]

See also an older similar bug 1745345.

[Ubuntu QA Website (ubuntuqa)]

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/1861609

[Sebastien Bacher (seb128)]

The issue got no recent duplicate, could it be fixed with the newest xorg? is anyone still seing the issue?

[Sebastien Bacher (seb128)]

tagging rls-ff-notfixing for now since it's not clear it's still an issue

[shemgp (shemgp)]

I reinstall focal from scratch and the issue is gone.

[Daniel van Vugt (vanvugt)]

It's certainly possible something has fixed it, like maybe the recent update to Xorg 1.20.8. Can anyone else confirm?

[Daniel van Vugt (vanvugt)]

It's hard to tell because errors.ubuntu.com is a bit broken (bug 1863689), but using a more targeted query you can see this bug is still the top crasher of Xorg even in the latest focal version:

https://errors.ubuntu.com/?release=Ubuntu%2020.04&package=xorg-server&period=week&version=2%3A1.20.8-2ubuntu2

[Steve Flynn (anothermindbomb)]

I installed the 20.04 Gnome ISO this morning - direct to disk - not in a VM.

No issues during the installation but upon rebooting I couldn't get past the login screen. I'd enter my password and the screen would flicker and I'd be put back to the login page.

Switching to a terminal and looking at the Xorg log showed me that it was crashing.

[ 597.161] (EE) Backtrace:
[ 597.161] (EE) 0: /usr/lib/xorg/Xorg (OsLookupColor+0x13c) [0x564dd4926dec]
[ 597.162] (EE) 1: /lib/x86_64-linux-gnu/libpthread.so.0 (funlockfile+0x60) [0x7f4ee513241f]
[ 597.163] (EE) 2: /lib/x86_64-linux-gnu/libc.so.6 (gsignal+0xcb) [0x7f4ee4f6f18b]
[ 597.163] (EE) 3: /lib/x86_64-linux-gnu/libc.so.6 (abort+0x12b) [0x7f4ee4f4e859]
[ 597.164] (EE) unw_get_proc_name failed: no unwind info found [-10]
[ 597.164] (EE) 4: /lib/x86_64-linux-gnu/libc.so.6 (?+0x0) [0x7f4ee4f4e71a]
[ 597.164] (EE) 5: /lib/x86_64-linux-gnu/libc.so.6 (__assert_fail+0x46) [0x7f4ee4f5ff36]
[ 597.164] (EE) 6: /usr/lib/xorg/Xorg (DRIMoveBuffersHelper+0xc15) [0x564dd48f1d65]
[ 597.164] (EE) 7: /usr/lib/xorg/Xorg (DRI2Authenticate+0xa2) [0x564dd48f33b2]
[ 597.164] (EE) 8: /usr/lib/xorg/Xorg (DRI2GetParam+0x944) [0x564dd48f4774]
[ 597.164] (EE) 9: /usr/lib/xorg/Xorg (SendErrorToClient+0x354) [0x564dd47c5f44]
[ 597.165] (EE) 10: /usr/lib/xorg/Xorg (InitFonts+0x3b4) [0x564dd47c9fd4]
[ 597.165] (EE) 11: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0xf3) [0x7f4ee4f500b3]
[ 597.165] (EE) 12: /usr/lib/xorg/Xorg (_start+0x2e) [0x564dd47b3a3e]
[ 597.165] (EE)
[ 597.165] (EE)
Fatal server error:
[ 597.165] (EE) Caught signal 6 (Aborted). Server aborting
[ 597.165] (EE)
[ 597.165] (EE)
Please consult the The X.Org Foundation support
         at http://wiki.x.org
 for help.
[ 597.165] (EE) Please also check the log file at "/home/steve/.local/share/xorg/Xorg.0.log" for additional information.
[ 597.165] (EE)
[ 597.207] (EE) Server terminated with error (1). Closing log file.

Some googling lead me to a page which pointed the finger at gstreamer. Removed it and that resolved the issue.

I should point out that I elected to not download updates during the installation process, so maybe if I had done so, this issue would be corrected before I got to see it but I can confirm Xorg was crashing on a freshly installed, 20.04 right out of the box.

[Daniel van Vugt (vanvugt)]

Thanks Steve. To be completely sure it's this bug we would need to see the log message from the assertion failure (run journalctl), but it looks likely to be this one.

When you say you removed "gstreamer", which packages do you mean?

[Steve Flynn (anothermindbomb)]

journalctl attached.

I had a few attempts at logging in at 11:37 or so, which gave me no clue as to what was going on, so I moved to a TTY and poked around for a bit. Googling took me to https://ubuntu-mate.community/t/20-04-workaround-for-xorg-crashes-to-login-prompt-in-virtual-machines/21368.

As you can see, I removed gstreamer1.0-vaapi at 11:55

May 27 11:55:12 lurcher sudo[9109]: steve : TTY=tty2 ; PWD=/home/steve/.local/share/xorg ; USER=root ; COMMAND=/usr/bin/apt-get purge gstreamer1.0-vaapi

That seemed to do the trick - I was able to login after a reboot.

(I then made the fatal error of turning on autologin for my account and found I was back at the same issue of not being able to get past the login screen the following morning but I believe that's a different bug).

Hopefully this is of some use.

S.

[Daniel van Vugt (vanvugt)]

Thanks Steve.

Your log file confirms it is this bug:

May 27 11:37:42 lurcher /usr/lib/gdm3/gdm-x-session[2452]: Xorg: ../../../../../../include/privates.h:121: dixGetPrivateAddr: Assertion `key->initialized' failed.

And the workaround of removing gstreamer1.0-vaapi was also discussed in bug 1796437 and bug 1745345. But the fact that any package can crash Xorg is still a Xorg bug, not a bug in that other package.

[Brett Nicholas (bigbrett)]

I have this on stock Ubuntu 20.04, but DON'T have gstreamer1.0-vaapi installed. Is there another workaround? My work laptop (Dell Precision 5540) is completely unusable and keeps crashing to the login screen

[Daniel van Vugt (vanvugt)]

Yes, just select 'Ubuntu on Wayland' from the login screen.

[Josué Casado Rabasco (geofisue)]

Hi, I have tried this solution, but when I use Ubuntu on Wayland, it goes extremely slow (for example the mouse pointer). Does anyone know why is it happening?

[Daniel van Vugt (vanvugt)]

Please open a new bug about the Wayland problem by running:

  ubuntu-bug gnome-shell

[Paul E Kasemir (pkasemir)]

I'm also running into this when running a VirtualBox version of Garuda linux using GDM.

I get the same assert failed.

It looks like the code doesn't properly check the values for the key.

I see this callflow.
dri2ClientPrivateKeyRec {size == 0, initialized == 0}
DRI2Authenticate()
dixLookupPrivate()
dixGetPrivate()
  assert(key->size == 0);
dixGetPrivateAddr()
  assert(key->initialized);

This flow expects initialized to be true, but it obviously is not.

Can we get this bug fixed finally?

[Daniel van Vugt (vanvugt)]

Seems like this is the #1 Xorg crasher in lunar:

https://errors.ubuntu.com/?release=Ubuntu%2023.04&package=xorg-server&period=week

[Daniel van Vugt (vanvugt)]

Tracking upstream in https://gitlab.freedesktop.org/xorg/xserver/-/issues/1053

[Sean Davis (bluesabre)]

I'd like to note that, on Xubuntu at least, these crashes are eliminated by removing libva-wayland2.

https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/2013071/comments/9

[Tobias Bühlmann (tbuehlmann)]

I have the same issue on Ubuntu 23.10 using VirtualBox 7.0.14 when using i3. It doesn't occur when logging in using Ubuntu (Gnome).

The issue doesn't occur when enabling 3D Acceleration in VirtualBox (but it slows down everything a lot).

Can also confirm uninstalling libva-wayland2 helps.

[Doug Brown (macg3)]

I'm running into this exact same problem with a fresh install of Xubuntu 24.04 running inside of VMware Workstation. During installation I did check both of the boxes about installing third party graphics/Wi-Fi software and downloading support for additional media formats.

Following along with comments from the upstream bug report at https://gitlab.freedesktop.org/xorg/xserver/-/issues/1053, I attempted to make DRI2Authenticate() more robust so that it doesn't hit the assertion if DRI2ScreenInit() hasn't been called yet:

--- a/hw/xfree86/dri2/dri2.c 2024-04-03 13:50:12.000000000 -0700
+++ b/hw/xfree86/dri2/dri2.c 2024-07-07 15:09:08.758039806 -0700
@@ -1362,9 +1362,14 @@ Bool
 DRI2Authenticate(ClientPtr client, ScreenPtr pScreen, uint32_t magic)
 {
     DRI2ScreenPtr ds;
- DRI2ClientPtr dri2_client = dri2ClientPrivate(client);
+ DRI2ClientPtr dri2_client;
     ScreenPtr primescreen;

+ if (!dri2ClientPrivateKey->initialized)
+ return FALSE;
+
+ dri2_client = dri2ClientPrivate(client);
+
     ds = DRI2GetScreenPrime(pScreen, dri2_client->prime_id);
     if (ds == NULL)
         return FALSE;

If I download the source code for xserver-xorg-core, apply this patch, build a new .deb, and install my newly built version of xserver-xorg-core_21.1.12-1ubuntu1_amd64.deb that includes this patch, the problem no longer occurs. I honestly have no idea what I'm doing inside the Xorg codebase though. Any chance someone with more experience than me on this package might be able to validate that the fix I made actually makes sense and is safe to do? It would be nice for Ubuntu to package a fix for this issue -- it's very annoying to have to log in twice after a reboot, and then deal with a bunch of apport crash warnings on various other xfce4 processes afterward.

Edit: The text formatting of the patch looks like it gets slightly screwed up by Launchpad, but it still gets the gist of the change across.

[Daniel van Vugt (vanvugt)]

I love your initiative, Doug.

Please mention that it works in the upstream bug (https://gitlab.freedesktop.org/xorg/xserver/-/issues/1053) because that's where the Xorg developers will see it.

[Doug Brown (macg3)]

Thank you, Daniel. I went ahead and posted my findings over there too.

One more thing I wanted to add over here: I've noticed a few people say that uninstalling libva-wayland2 also fixes it. I can confirm that too, but I looked deeper and discovered that what's actually fixing it is uninstalling gstreamer1.0-vaapi. When you uninstall libva-wayland2, apt also uninstalls gstreamer1.0-vaapi.

If you leave libva-wayland2 installed and uninstall gstreamer1.0-vaapi instead, that also fixes the crash. In particular, the file /usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstvaapi.so seems to be the culprit (that's the main file installed by gstreamer1.0-vaapi). If I just move that file to my desktop and reboot, the Xorg crashing problem goes away.

I'm not sure about the interaction between that GStreamer plugin and DRI2Authenticate being called too early, but it's definitely an interesting clue. At first I thought this was nonsense -- how could a GStreamer plugin cause Xorg to crash on login? -- but sure enough, it seems to be involved at some level.

[Daniel van Vugt (vanvugt)]

Anything that uses VAAPI in a Xorg session would have to call DRI2Authenticate and related functions to access the video decoding hardware. So it's surprising but makes sense.

[Doug Brown (macg3)]

That makes sense. I added some icky debug printouts inside of the gstreamer1.0-vaapi plugin to see if I could better understand what's going on with this issue.

What's happening in Xubuntu is when you log in, tumblerd starts up. tumblerd is a thumbnail creator, so it makes sense that it would interact with GStreamer. tumblerd ends up doing something that invokes gst-plugin-scanner, which loads the GStreamer vaapi plugin and leads to the crash. The second time you log in, tumblerd is already running so it doesn't repeat the plugin scan process and thus doesn't crash. But, you can also cause the X11 crash to happen again at any time by typing:

gst-inspect-1.0

into your terminal. This crashes repeatably every time for me. Basically GStreamer is completely useless in Xubuntu 24.04 right now, at least inside of a VMware VM.

In fact, I can install a different flavor of Ubuntu such as Ubuntu MATE in a VM, and install the problematic plugins:

sudo apt install gstreamer1.0-vaapi gstreamer1.0-tools

...and cause the exact same crash to occur by running gst-inspect-1.0.

Here's a backtrace of the code path in gst-plugin-scanner that is leading to the request to Xorg that crashes it. No idea where the fault lies, but something about this sequence makes Xorg unhappy:

#0 _XReply (dpy=dpy@entry=0x55555558dce0, rep=rep@entry=0x7fffffffd6f0, extra=extra@entry=0, discard=discard@entry=0)
    at ../../src/xcb_io.c:680
#1 0x00007ffff752a3d0 in VA_DRI2Authenticate (dpy=dpy@entry=0x55555558dce0, window=1046, magic=magic@entry=1)
    at ../va/x11/va_dri2.c:225
#2 0x00007ffff7c138ed in va_drm_authenticate_x11 (fd=fd@entry=6, magic=magic@entry=1) at ../va/drm/va_drm_auth_x11.c:140
#3 0x00007ffff7c135d5 in va_drm_authenticate (fd=6, magic=1) at ../va/drm/va_drm_auth.c:37
#4 0x00007ffff7c134bd in va_DisplayContextConnect (pDisplayContext=<optimized out>) at ../va/drm/va_drm.c:62
#5 va_DisplayContextGetDriverNames (pDisplayContext=<optimized out>, drivers=0x7fffffffd890, num_drivers=0x7fffffffd884)
    at ../va/drm/va_drm.c:79
#6 0x00007ffff781729e in va_new_opendriver (dpy=0x55555558d310) at ../va/va.c:681
#7 vaInitialize
    (dpy=dpy@entry=0x55555558d310, major_version=major_version@entry=0x7fffffffdb34, minor_version=minor_version@entry=0x7fffffffdb30) at ../va/va.c:743
#8 0x00007ffff7f496d0 in vaapi_initialize (dpy=0x55555558d310) at ../gst-libs/gst/vaapi/gstvaapiutils.c:113
#9 0x00007ffff7f6db73 in supports_vaapi (fd=6) at ../gst-libs/gst/vaapi/gstvaapidisplay_drm.c:77
#10 get_default_device_path (display=0x5555555892a0 [GstVaapiDisplayDRM|vaapidisplaydrm1])
    at ../gst-libs/gst/vaapi/gstvaapidisplay_drm.c:140
#11 set_device_path (device_path=<optimized out>, display=0x5555555892a0 [GstVaapiDisplayDRM|vaapidisplaydrm1])
    at ../gst-libs/gst/vaapi/gstvaapidisplay_drm.c:181
#12 gst_vaapi_display_drm_open_display (display=0x5555555892a0 [GstVaapiDisplayDRM|vaapidisplaydrm1], name=<optimized out>)
    at ../gst-libs/gst/vaapi/gstvaapidisplay_drm.c:247
#13 0x00007ffff7f4a68b in gst_vaapi_display_create
    (data=0x0, init_type=GST_VAAPI_DISPLAY_INIT_FROM_DISPLAY_NAME, display=0x5555555892a0 [GstVaapiDisplayDRM|vaapidisplaydrm1])
    at ../gst-libs/g...

[Doug Brown (macg3)]

One more thing, I also noticed that it only happens when 3D acceleration is disabled (or unavailable) in VMware. This jives with what Tobias mentioned about VirtualBox above.

[Matthew Ruffell (mruffell)]

Hi Doug,

You have done some awesome work! Thank you very much for debugging and opening a merge request upstream.

I can reproduce the issue, and yes, your patch with the help of previous authors does fix the issue.

Hopefully we can try and get the attention of the maintainers, and see if they are interested in pulling the patch in.

In the meantime, I built some test packages to share if anyone wants to try the patch out.

Please note this package is NOT SUPPORTED by Canonical, and is for TESTING
PURPOSES ONLY. ONLY Install in a dedicated test environment.

Instructions to Install (On a focal, jammy, noble or oracular system):
1) sudo add-apt-repository ppa:mruffell/sf392117-test
2) sudo apt update
3) sudo apt install xserver-common xserver-xephyr xserver-xorg-core xserver-xorg-legacy
4) sudo apt-cache policy xserver-common | grep Installed
Oracular:
2:21.1.12-1ubuntu1+sf392117v20240813b1
Noble:
2:21.1.12-1ubuntu1+sf392117v20240813b0
Jammy:
2:21.1.4-2ubuntu1.7~22.04.11+sf392117v20240813b1
Focal:
2:1.20.13-1ubuntu1~20.04.17+sf392117v20240813b1

You probably want to run it in a VM. Probably best to reboot after installing
before trying to reproduce.

Thanks,
Matthew

[Doug Brown (macg3)]

Thanks Matthew! I'm not sure what it will take to get the attention of the Xorg maintainers. At some point I also wonder if distros like Ubuntu could add the patch to their own builds to fix the bug. It's definitely a weird one.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Marc (teaberries)]

FYI: I have the some problem as Doug mentioned (fresh install of Xubuntu 24.04, although it's the .1 release), but I do not have deep technical knowledge, so I don't think I'd be able to implement any kind of workaround.

Does anybody know if and when the problem will be fixed (and if I can just use the normal system update mechanisms to get a fix)?

Thanks!

[Matthew Ruffell (mruffell)]

Hi Marc,

You can use the test packages I made in comment #31 as a workaround for the time being.

We are currently waiting on upstream to review the merge request here:

https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1608

There hasn't been a lot of movement, but we can't move forward fixing Ubuntu until it gets merged upstream.

Thanks,
Matthew

[Marc (teaberries)]

Thanks for the explanation and your help!

[Matthew Ruffell (mruffell)]

We have been waiting for a very long time. I am giving up on upstream merging the commits. Let's vendor the patch. New debdiffs inbound. SRU template ready.

[Matthew Ruffell (mruffell)]

Attached is a debdiff for plucky which fixes this issue.

[Matthew Ruffell (mruffell)]

Attached is a debdiff for oracular which fixes this issue.

[Matthew Ruffell (mruffell)]

Debdiff for xorg-server on noble which solves this issue.

[Matthew Ruffell (mruffell)]

Attached is a debdiff for jammy which solves this issue.

[Matthew Ruffell (mruffell)]

Debdiff for xorg-server on focal which solves this issue. I think its important enough to fix before focal archive closure.

[Sean Davis (bluesabre)]

Do you anticipate this being fixed in time for 24.04.2?

[Matthew Ruffell (mruffell)]

Hi Sean,

Unlikely for 24.04.2 sorry. I am still trying to get the autopkgtests to pass for plucky. This should make 25.04 though.

Will be out as soon as I can get it out.

Thanks,
Matthew

[Matthew Ruffell (mruffell)]

It just got merged!

https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1608

commit a0834009cfb10b8982a1f2b47b8ed00de254c2c3
From: Doug Brown <email address hidden>
Date: Mon, 15 Jul 2024 19:44:23 -0700
Subject: dri2: Protect against dri2ClientPrivate assertion failures
Link: https://gitlab.freedesktop.org/xorg/xserver/-/commit/a0834009cfb10b8982a1f2b47b8ed00de254c2c3

[Matthew Ruffell (mruffell)]

V2 debdiff for oracular that reflects origin to upstreamed patch.

[Matthew Ruffell (mruffell)]

V2 debdiff for noble that reflects origin to upstreamed patch.

[Matthew Ruffell (mruffell)]

V2 debdiff for jammy that reflects origin to upstreamed patch.

[Matthew Ruffell (mruffell)]

V2 debdiff for focal that reflects origin to upstreamed patch.

[Launchpad Janitor (janitor)]

This bug was fixed in the package xorg-server - 2:21.1.16-1ubuntu1

---------------
xorg-server (2:21.1.16-1ubuntu1) plucky; urgency=medium

  * Merge from Debian.
  * lp1861609-dri2-Protect-against-dri2ClientPrivate-assertio.patch:
    Dropped, upstream.

 -- Timo Aaltonen <email address hidden> Wed, 26 Feb 2025 15:02:02 +0200

[Matthew Ruffell (mruffell)]

V3 Patch for oracular that is rebased ontop of the latest security update.

[Matthew Ruffell (mruffell)]

V3 Patch for noble that is rebased ontop of the latest security update.

[Matthew Ruffell (mruffell)]

V3 Patch for jammy that is rebased ontop of the latest security update.

[Matthew Ruffell (mruffell)]

V3 Patch for focal that is rebased ontop of the latest security update.

[Matthew Ruffell (mruffell)]

Uploaded to O, N, J and F.

To the SRU Team: I do understand that F is going to ESM very soon, and you
likely don't want to change F very much this late in its lifecycle, but if you
look at

https://errors.ubuntu.com/?release=Ubuntu%2020.04&package=xorg-server&period=week

for the last week, we see the bug at Number 3 and 6, so fixing this would have
a real impact on end users for some time to come.

[Timo Aaltonen (tjaalton)]

Hello linex83, or anyone else affected,

Accepted xorg-server into oracular-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/xorg-server/2:21.1.13-2ubuntu1.3 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-oracular to verification-done-oracular. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-oracular. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Timo Aaltonen (tjaalton)]

Hello linex83, or anyone else affected,

Accepted xorg-server into noble-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/xorg-server/2:21.1.12-1ubuntu1.3 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-noble to verification-done-noble. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-noble. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Timo Aaltonen (tjaalton)]

Hello linex83, or anyone else affected,

Accepted xorg-server into jammy-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/xorg-server/2:21.1.4-2ubuntu1.7~22.04.14 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-jammy to verification-done-jammy. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-jammy. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Timo Aaltonen (tjaalton)]

Hello linex83, or anyone else affected,

Accepted xorg-server into focal-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/xorg-server/2:1.20.13-1ubuntu1~20.04.20 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-focal to verification-done-focal. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-focal. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Ubuntu SRU Bot (ubuntu-sru-bot)]

All autopkgtests for the newly accepted xorg-server (2:21.1.4-2ubuntu1.7~22.04.14) for jammy have finished running.
The following regressions have been reported in tests triggered by the package:

aevol/5.0+ds-3 (amd64, ppc64el)
aevol/unknown (arm64)
at-spi2-core/unknown (armhf)
bambam/unknown (armhf)
binclock/unknown (armhf)
blackbox/unknown (armhf)
butt/unknown (armhf)
calf/unknown (armhf)
camitk/5.0.2-3 (amd64)
dbus/1.12.20-2ubuntu4.1 (s390x)
firejail/0.9.66-2 (amd64, arm64)
gjs/unknown (armhf, ppc64el)
glib-networking/unknown (armhf)
glib2.0/unknown (armhf)
gnome-feeds/0.16.2+dfsg1-1 (arm64)
gnome-photos/unknown (armhf)
gpick/unknown (armhf)
gramofile/unknown (armhf)
gscan2pdf/2.12.6-1 (ppc64el)
gscan2pdf/unknown (armhf)
gspell/unknown (armhf)
gtk+3.0/3.24.33-1ubuntu2.2 (ppc64el)
gtk+3.0/unknown (armhf)
gtk4/unknown (armhf)
imagination/3.6-1build1 (amd64)
krop/unknown (armhf)
libhandy-1/1.6.1-1 (arm64)
libsoup2.4/2.74.2-3ubuntu0.1 (amd64)
libsoup3/3.0.7-0ubuntu1 (amd64)
nvidia-graphics-drivers-390/unknown (armhf)
openjdk-21/21.0.6+7-1~22.04.1 (s390x)
openjdk-8/8u442-b06~us1-0ubuntu1~22.04 (amd64, arm64)
openmsx/17.0-1ubuntu3 (arm64)
openmsx/unknown (ppc64el)
pandas/1.3.5+dfsg-3 (arm64)
pango1.0/1.50.6+ds-2ubuntu1 (arm64)
pytest-qt/unknown (ppc64el)
sasview/5.0.4-1 (amd64)
valentina/0.7.49~dfsg-2 (amd64)
vorta/unknown (armhf)

Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-migration/jammy/update_excuses.html#xorg-server

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

[Ubuntu SRU Bot (ubuntu-sru-bot)]

All autopkgtests for the newly accepted xorg-server (2:1.20.13-1ubuntu1~20.04.20) for focal have finished running.
The following regressions have been reported in tests triggered by the package:

apport/2.20.11-0ubuntu27.27 (armhf)
firejail/0.9.62-3ubuntu0.1 (amd64)
firejail/unknown (armhf)
khtml/5.68.0-0ubuntu1 (s390x)
kitemmodels/5.68.0-0ubuntu1 (amd64)
libsoup2.4/2.70.0-1ubuntu0.1 (arm64)
nvidia-graphics-drivers-390/unknown (armhf)
openjdk-21/21.0.6+7-1~20.04.1 (s390x)
openjdk-21/unknown (armhf)
openscad/2019.05-3ubuntu5 (amd64)
saods9/8.1+repack-1 (ppc64el)
silx/0.12.0+dfsg-1build1 (amd64)
umbrello/4:19.12.3-0ubuntu1 (amd64)
virtaal/unknown (armhf)
xarclock/unknown (armhf)

Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-migration/focal/update_excuses.html#xorg-server

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

[Ubuntu SRU Bot (ubuntu-sru-bot)]

All autopkgtests for the newly accepted xorg-server (2:21.1.12-1ubuntu1.3) for noble have finished running.
The following regressions have been reported in tests triggered by the package:

bambam/1.2.1+dfsg-1 (s390x)
beast2-mcmc/2.7.6+dfsg-1 (ppc64el)
cjs/6.0.0-2build3 (arm64)
dbus/1.14.10-4ubuntu4.1 (ppc64el, s390x)
finalcif/134+dfsg-1 (amd64, arm64, armhf, i386)
firejail/0.9.72-2ubuntu3 (amd64)
gnuplot-iostream/unknown (armhf)
gtk4/4.14.2+ds-1ubuntu1 (ppc64el)
libhandy/0.0.13-3build2 (s390x)
lomiri-settings-components/1.1.1-1build2 (s390x)
mediainfo/24.01.1-1build2 (s390x)
openjdk-8/8u442-b06~us1-0ubuntu1~24.04 (i386, ppc64el)
pandas/unknown (ppc64el)
pipewalker/unknown (armhf)
pyatspi/unknown (armhf)
pygrace/unknown (armhf)
pyotherside/unknown (armhf)
pysatellites/2.7-2 (arm64)
pytrainer/2.2.1-4 (amd64)
rust-gtk4/0.8.1-1 (s390x)
rust-gtk4/unknown (arm64)
seaborn/0.13.2-3 (arm64)
spectrwm/unknown (armhf)
texworks/0.6.8-3build4 (amd64)
ubiquity/24.04.5 (amd64)
ubiquity/unknown (armhf)

Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-migration/noble/update_excuses.html#xorg-server

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

[Ubuntu SRU Bot (ubuntu-sru-bot)]

All autopkgtests for the newly accepted xorg-server (2:21.1.13-2ubuntu1.3) for oracular have finished running.
The following regressions have been reported in tests triggered by the package:

aevol/5.0+ds-3ubuntu1 (ppc64el)
alttab/1.7.1-3 (s390x)
dbus/1.14.10-4ubuntu5 (s390x)
finalcif/137+dfsg-1 (amd64, arm64, armhf, i386)
firejail/0.9.72-2ubuntu3 (amd64)
freecad/0.21.2+dfsg1-6 (amd64)
glib2.0/2.82.1-0ubuntu1 (ppc64el)
gnome-chemistry-utils/0.14.17-6.2build2 (ppc64el)
gnome-mastermind/0.4.0-4build2 (arm64)
gnudatalanguage/1.0.6-1 (arm64)
gtk+2.0/2.24.33-5ubuntu2 (arm64)
gtk4/4.16.3+ds-0ubuntu1 (amd64)
mediaconch/unknown (armhf)
mediainfo/unknown (armhf)
miwm/1.1-9build1 (s390x)
miwm/unknown (armhf)
mutter/unknown (armhf)
navarp/1.6.0-4 (amd64)
navarp/unknown (armhf)
netmate/unknown (armhf)
nfoview/unknown (armhf)
openjdk-22/22.0.2+9-4 (arm64, ppc64el)
openjdk-23/23.0.2+7-1ubuntu1~24.10 (amd64, s390x)
openjdk-23/unknown (armhf)
openjdk-24/24~16ea-1 (amd64)
openjdk-8/8u442-b06~us1-0ubuntu1~24.10 (amd64, arm64, ppc64el, s390x)
openmsx/19.1+dfsg-1ubuntu3 (arm64)
pandas/unknown (armhf)
rust-gtk4/0.9.1-2 (amd64, s390x)
rust-gtk4-macros/0.9.0-3 (amd64)
spyder/5.5.1+ds-2 (amd64)
vim-ale/3.3.0-1 (s390x)
wesnoth-1.18/1:1.18.2-1 (s390x)

Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-migration/oracular/update_excuses.html#xorg-server

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

[Doug Brown (macg3)]

I can confirm that in an Ubuntu MATE 24.04 VMware VM with "Accelerate 3D graphics" disabled, the version currently in noble-proposed fixes the issue. Same with Xubuntu 24.04.

`gst-inspect-1.0` no longer crashes when I have xserver-xorg-core version 2:21.1.12-1ubuntu1.3 from noble-proposed installed.

Testing performed with Ubuntu MATE:

- Create a VMware VM, make sure "Accelerate 3D graphics" is disabled
- Install Ubuntu MATE 24.04.2 from ISO, check all the boxes for optional stuff when installing it
- Fully update it with `sudo apt update; sudo apt dist-upgrade`
- `sudo apt install gstreamer1.0-tools`
- Confirm the crash is still happening: `gst-inspect-1.0`
- Enable -proposed, then `sudo apt update`
- `sudo apt install xserver-xorg-core/noble-proposed`
- Reboot
- Confirm it doesn't crash anymore: `gst-inspect-1.0`

Testing performed with Xubuntu:

- Create a VMware VM, make sure "Accelerate 3D graphics" is disabled
- Install Xubuntu 24.04.2 from ISO, check all the boxes for optional stuff when installing it
- Fully update it with `sudo apt update; sudo apt dist-upgrade`
- Confirm the crash is still happening: the first time you try to log in after rebooting, it crashes back to the login screen, and then subsequent login attempts work fine
- Enable -proposed, then `sudo apt update`
- `sudo apt install xserver-xorg-core/noble-proposed`
- Reboot
- Confirm that the first login attempt always works now

[Matthew Ruffell (mruffell)]

Performing verification for Oracular.

I created a fresh Oracular VMn and upgraded all packages.

xserver is at version:

sudo apt-cache policy xserver-common | grep Installed
Installed: 2:21.1.13-2ubuntu1.2

I then installed a gstreamer stack:

sudo apt install gstreamer1.0-vaapi gstreamer1.0-tools

I then triggered the crash:
gst-inspect-1.0

and xserver crashed as expected. I then try and log in, and I can't even log
in anymore due to the thumbnailer calling gstreamer and xserver immediately
crashes.

I changed to a wayland session, enabled -proposed and installed xserver
2:21.1.13-2ubuntu1.3.

I rebooted, and selected xorg session from gdm.

I can log in now, and the desktop comes up as normal.

I then tried to trigger the crash:

gst-inspect-1.0

and it completes as expected.

The package in -proposed fixes the issue, happy to mark verified for oracular.

[Matthew Ruffell (mruffell)]

Performing verification for Noble.

I created a fresh Noble VMn and upgraded all packages.

xserver is at version:

sudo apt-cache policy xserver-common | grep Installed
Installed: 2:21.1.12-1ubuntu1.2

I then installed a gstreamer stack:

sudo apt install gstreamer1.0-vaapi gstreamer1.0-tools

I then triggered the crash:
gst-inspect-1.0

and xserver crashed as expected. I then try and log in, and I can't even log
in anymore due to the thumbnailer calling gstreamer and xserver immediately
crashes.

I changed to a wayland session, enabled -proposed and installed xserver
2:21.1.12-1ubuntu1.3

I rebooted, and selected xorg session from gdm.

I can log in now, and the desktop comes up as normal.

I then tried to trigger the crash:

gst-inspect-1.0

and it completes as expected.

I agree with Doug, the package in -proposed fixes the issue, happy to mark verified for noble.

[Matthew Ruffell (mruffell)]

Performing verification for jammy.

I installed a fresh Jammy desktop VM, and installed all updates.

sudo apt-cache policy xserver-common | grep Installed
Installed: 2:21.1.4-2ubuntu1.7~22.04.13

I then installed a gstreamer stack:

sudo apt install gstreamer1.0-vaapi gstreamer1.0-tools

I then triggered the crash:
gst-inspect-1.0

This doesn't reproduce on jammy as is, not on this mechanism anyway. I know the
crash occurs as I can see it on:

https://errors.ubuntu.com/?release=Ubuntu%2022.04&package=xorg-server&period=week

After reading

https://github.com/intel/libva/issues/700

I downloaded the libva source for jammy 2.14.0-1, and backported the following
patch:

https://github.com/intel/libva/commit/317c0fbea5405a27bf58505a6bc6b1f6414beb71

The backport is:

https://paste.ubuntu.com/p/nNy3rsZj8w/

I built this, and installed the test packages.

I then run:

gst-inspect-1.0

now xserver crashes as we would expect. I also can't log in now either due to
xserver crashing. So we can now reproduce the crash.

I changed to a wayland session, enabled -proposed and installed xserver
2:21.1.4-2ubuntu1.7~22.04.14

I rebooted, and selected xorg session from gdm.

I can log in now, and the desktop comes up as normal.

I then tried to trigger the crash:

gst-inspect-1.0

and it completes as expected. xserver does not crash.

The package in -proposed fixes the issue, happy to mark verified for jammy.

[Matthew Ruffell (mruffell)]

Performing verification for focal.

I installed a fresh Focal desktop VM, and installed all updates.

sudo apt-cache policy xserver-common | grep Installed
Installed: 2:1.20.13-1ubuntu1~20.04.19

I then installed a gstreamer stack:

sudo apt install gstreamer1.0-vaapi gstreamer1.0-tools

I then triggered the crash:
gst-inspect-1.0

This doesn't reproduce on jammy as is, not on this mechanism anyway. I know the
crash occurs as I can see it on:

https://errors.ubuntu.com/?release=Ubuntu%2022.04&package=xorg-server&period=week

After reading

https://github.com/intel/libva/issues/700

I downloaded the libva source for focal 2.7.0-2, and backported the following
patch:

https://github.com/intel/libva/commit/317c0fbea5405a27bf58505a6bc6b1f6414beb71

The backport is:

https://paste.ubuntu.com/p/nNy3rsZj8w/

I built this, and installed the test packages.

I then run:

gst-inspect-1.0

xserver doesn't crash, which is again a bit frustrating.

I re-read

https://github.com/intel/libva/issues/700

and came across the reproducer program:

test-vaInitialize.c
/*
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 built it and ran it:

gcc -O0 -g test-vaInitialize.c -lva -lva-drm -o test-vaInitialize
DISPLAY=:0 ./test-vaInitialize

This crashes the xserver, as we expect it to. Now we have a stable reproducer.

I changed to a wayland session, enabled -proposed and installed xserver
2:1.20.13-1ubuntu1~20.04.20

I rebooted, and selected xorg session from gdm.

I then tried to trigger the crash:

gst-inspect-1.0
and
DISPLAY=:0 ./test-vaInitialize

and it completes as expected. xserver does not crash.

The package in -proposed fixes the issue, happy to mark verified for focal.

[Launchpad Janitor (janitor)]

This bug was fixed in the package xorg-server - 2:1.20.13-1ubuntu1~20.04.20

---------------
xorg-server (2:1.20.13-1ubuntu1~20.04.20) focal; urgency=medium

  * If a client application has not called DRI2ScreenInit(),
    DRI2Authenticate() and DRI2CreateDrawable2() cause the X server to
    crash. This patch adds some sanity checks to ensure the X server
    stays running. (LP: #1861609)
    - d/p/lp1861609-dri2-Protect-against-dri2ClientPrivate-assertio.patch

 -- Matthew Ruffell <email address hidden> Tue, 04 Mar 2025 18:35:23 +1300

[Chris Halse Rogers (raof)]

The verification of the Stable Release Update for xorg-server has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

[Launchpad Janitor (janitor)]

This bug was fixed in the package xorg-server - 2:21.1.4-2ubuntu1.7~22.04.14

---------------
xorg-server (2:21.1.4-2ubuntu1.7~22.04.14) jammy; urgency=medium

  * If a client application has not called DRI2ScreenInit(),
    DRI2Authenticate() and DRI2CreateDrawable2() cause the X server to
    crash. This patch adds some sanity checks to ensure the X server
    stays running. (LP: #1861609)
    - d/p/lp1861609-dri2-Protect-against-dri2ClientPrivate-assertio.patch

 -- Matthew Ruffell <email address hidden> Tue, 04 Mar 2025 18:21:58 +1300

[Launchpad Janitor (janitor)]

This bug was fixed in the package xorg-server - 2:21.1.12-1ubuntu1.3

---------------
xorg-server (2:21.1.12-1ubuntu1.3) noble; urgency=medium

  * If a client application has not called DRI2ScreenInit(),
    DRI2Authenticate() and DRI2CreateDrawable2() cause the X server to
    crash. This patch adds some sanity checks to ensure the X server
    stays running. (LP: #1861609)
    - d/p/lp1861609-dri2-Protect-against-dri2ClientPrivate-assertio.patch

 -- Matthew Ruffell <email address hidden> Tue, 04 Mar 2025 17:58:03 +1300

[Launchpad Janitor (janitor)]

This bug was fixed in the package xorg-server - 2:21.1.13-2ubuntu1.3

---------------
xorg-server (2:21.1.13-2ubuntu1.3) oracular; urgency=medium

  * If a client application has not called DRI2ScreenInit(),
    DRI2Authenticate() and DRI2CreateDrawable2() cause the X server to
    crash. This patch adds some sanity checks to ensure the X server
    stays running. (LP: #1861609)
    - d/p/lp1861609-dri2-Protect-against-dri2ClientPrivate-assertio.patch

 -- Matthew Ruffell <email address hidden> Tue, 04 Mar 2025 17:31:15 +1300