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

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.]

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.

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

See also an older similar bug 1745345.

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

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

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

I reinstall focal from scratch and the issue is gone.

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

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

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.

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?

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.

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.

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

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

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?

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

  ubuntu-bug gnome-shell

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?

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

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

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

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

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.

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.

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.

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.

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.

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...

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.

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

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.

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

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!

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

Thanks for the explanation and your help!

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.

Attached is a debdiff for plucky which fixes this issue.

Attached is a debdiff for oracular which fixes this issue.

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

Attached is a debdiff for jammy which solves this issue.

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

Do you anticipate this being fixed in time for 24.04.2?

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

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

V2 debdiff for oracular that reflects origin to upstreamed patch.

V2 debdiff for noble that reflects origin to upstreamed patch.

V2 debdiff for jammy that reflects origin to upstreamed patch.

V2 debdiff for focal that reflects origin to upstreamed patch.

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

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

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

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

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

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.

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.

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.

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.

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.

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!

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!

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!

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!

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

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.

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.

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.

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.