Xorg crashed with assertion failure (usually in a VM) at [privates.h:121/122: dixGetPrivateAddr: Assertion `key->initialized' failed]

[linex83]

Xorg crashed with assertion failure (usually in a VM):

privates.h:121: dixGetPrivateAddr: Assertion `key->initialized' failed.

WORKAROUND

Select 'Ubuntu on Wayland' on the login screen.

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