Created attachment 645546 [details] gdb log of /usr/bin/X including backtrace Starting /usr/bin/spicy from net-misc/spice-gtk-0.37-r2 immediately crashes the Xorg server: X: ../../../include/privates.h:121: dixGetPrivateAddr: Assertion `key->initialized' failed. GDB log attached as file. x11-base/xorg-server-1.20.8:0/1.20.8::gentoo USE="dmx doc elogind ipv6 libglvnd static-libs udev unwind wayland xnest xorg xvfb -debug -kdrive -libressl -minimal (-selinux) -suid -systemd -xcsecurity -xephyr" x11-base/xorg-drivers-1.20-r2::gentoo INPUT_DEVICES="libinput synaptics wacom -elographics -evdev -joystick -vmmouse -void" VIDEO_CARDS="fbdev -amdgpu -ast -dummy (-freedreno) (-geode) -glint -i915 -i965 -intel -mga -nouveau -nv -nvidia (-omap) -qxl -r128 -radeon -radeonsi -siliconmotion (-tegra) (-vc4) -vesa -via -virtualbox -vmware"
xorg-server-1.20.7 crashes as well.
Since this bug causes the whole X session to crash, most (if not all) user processes in the session to terminate, and any unsaved data and state being lost, I object to marking this bug "Normal", which according to https://bugs.gentoo.org/enter_bug.cgi?product=Gentoo%20Linux&format=guided is "Normal: It's a bug that should be fixed." The fallout of this bug twice caused a fair amount of damage, and I apologize if I'm too emotional about it. But I'm currently reverting this to "Critical: The software crashes, hangs, or causes you to lose data." which I believe objectively reflects the seriousness of this issue, especially given that both spicy and virt-manager trigger the crash and are hence unusable for the purpose of accessing some remote virtual machines via the SPICE protocol.
Ouch. A few questions: Did this work with a previous version of xorg-server? Or a previous version of some other software? Mesa, spice, etc?
(In reply to Matt Turner from comment #3) > Did this work with a previous version of xorg-server? Or a previous version > of some other software? Mesa, spice, etc? It used to work with xorg-server-1.20.7. Perhaps it has something to do with the upgrade of Mesa from 19.3.5 to 20.1.1, which could explain why this started happening. I will investigate whether downgrading mesa will help.
I tried with media-libs/mesa versions 19.3.5 (with patch from #706234) and 20.0.8 as well. The version of Mesa used seems to make no difference. Is switching from VIDEO_CARDS="fbdev intel modesetting nouveau i965 i915" to simply VIDEO_CARDS="modesetting" is also something which might have contributed to this bug occurring? I'd rather not switch back to those Intel-specific GPU drivers, because these caused some nauseous flickering (i.e. which looked like random memory written to pixels in certain regions of the screen when moving the mouse).
(In reply to Jaak Ristioja from comment #5) > I tried with media-libs/mesa versions 19.3.5 (with patch from #706234) and > 20.0.8 as well. The version of Mesa used seems to make no difference. > > Is switching from VIDEO_CARDS="fbdev intel modesetting nouveau i965 i915" to > simply VIDEO_CARDS="modesetting" is also something which might have > contributed to this bug occurring? Yes, you were probably using the xf86-video-intel DDX before and now you're using the modesetting driver. Could you file a bug upstream at https://gitlab.freedesktop.org/xorg/xserver/-/issues and link to it from here?
(In reply to Matt Turner from comment #6) > Could you file a bug upstream at > https://gitlab.freedesktop.org/xorg/xserver/-/issues and link to it from > here? Nope, not at the moment, sorry! I actually tried for hours, but their GitLab "anti-spam" system doesn't let me file an issue, complaining about me not solving some captcha, but it doesn't even display one. Maybe I have some more time to debug this captcha thing after my summer vacation...
Please test v1.20.10.