starting steam crashes X11-session since yesterday's package-upgrade

dr1fter · 2022-01-21 21:16:24

I have been using steam for the past ~two (or is it three already?) years almost daily. I am very well aware of the wiki-page, and already successfully did some trouble-shooting some months back, when launching steam failed.

I typically do a full package-upgrade daily (pacman -Syu), sometimes more than once per day. After yesterday's package-upgrade I also rebooted, because docker would no longer start due to a kernel-module-change stemming from an upgrade of pkg `linux`.

After said reboot, starting steam (the gui version) reproducibly will result in a black screen, followed by a brief display of some systemd logs (too short for me to be able to read anything), followed by a newly initialised (empty) Desktop (I am using Cinnamon). Empty meaning all of my processes/windows gone. The desktop configuration is exactly as I would expect it after either a reboot, or a restart of Cinnamon.

I checked both `dmesg` and all log files below `/var/log` (of course including X11 + errors.log), and could not find anything that even remotely looked like an actual error (just some few warnings that I think are just part of the "usual" noise).

I performed a full pkg upgrade today, and even performed another reboot (tbh I feel very lame for doing a reboot trying to fix things..). Same error. I looked very thoroughly into all log files below `/var/log`, repeatedly, and even looked through the warnings, based on timestamp.

What I forgot to mention: I also reset steam (`steam-runtime --reset`), also followed by a reboot (still: same result).

Finally, I started a steam-managed application (okay, a game..) "directly" through its launcher from the "start menu", instead of trying to start the steam-ui first. After asking me to login again (strangely enough), the requested application would start. And so would the steam-ui.

Sooo.... what I would be very interested in would be places to look for further logs to find the root-cause of the described error. Btw: `/tmp/dumps` was always an empty directory when I checked (this is named as a place to look for steam-logs in the archwiki-page for steam)

Any hints very apreciated :-)

seth · 2022-01-22 09:01:55

dmesg will only hold kernelspace errors/crashes and /var/log isn't the position of the (current) Xorg log, depending on how you start X11 - check the log date inside the log.
The symptoms *can* reflect a crash of the X11 server (though those are typically logged in the tail of the X11 log - notably "Xorg.0.log.old" because Xorg.0.log is now the running server) but can also indicate a crash/termination of the session process and even the DM (if any)

* sudo journalctl
* coredumpctl
* ~/.xsession-errors
* https://wiki.archlinux.org/title/Xorg#General

dr1fter · 2022-01-22 21:08:57

> /var/log isn't the position of the (current) Xorg log, depending on how you start X11 - check the log date inside the log.

it is not? `ls -lta /var/log` gave me: Xorg.0.log + Xorg.0.log.old, both with matching mod-timestamps (only checking the `.old` one makes sense, of course. I checked both the other day).

Thanks for hinting about ~/.xsession-errors - I was not aware of this logfile (and unfortunately it no longer contains relevant log entries, based on contained timestamps)

I even tried to check `journalctl? - however I gave up after finding out it seems to be flooded w/ log-entries from some bluetooth-related error. When trying to navigate to the bottom (`G`), it would freeze for several tens of seconds. Scrolling manually would likely take inconveniently long. I suppose I should spend some hours reading journalctl's manpage (I have to admit I am very when it comes to using anything stemming from systemd - their CLIs seem to be completely incompatible with my intuition :-/)

DM would be my Desktop-Manager? I am using Cinnamon (so that would be my DM?) Or would it be the underlying mutter-thingy?

At either rate, after launching a single game through its "start menu entry", as opposed to firstly starting the steam-UI, I can now no longer reproduce the crash (whcih was before that occurring 100% reproducibly). So unless it will likely prove to be difficult to further debug the for the root-cause :-(

btw, `coredumpctl` was also a very good hint (I did not know it so far). the output it gave (filtered for relevant period of time) reads:

Sun 2022-01-16 22:49:57 CET 161757 1000 1000 SIGABRT missing      /usr/bin/python3.10                   >
Mon 2022-01-17 08:56:55 CET  11592 1000 1000 SIGILL  missing      /usr/share/teams/teams                >
Mon 2022-01-17 09:26:42 CET 206273 1000 1000 SIGQUIT missing      /usr/share/teams/resources/app.asar.un>
Mon 2022-01-17 20:55:46 CET 173863 1000 1000 SIGILL  missing      /usr/share/teams/teams                >
Mon 2022-01-17 20:57:29 CET 161829    0    0 SIGSEGV missing      /usr/lib/bluetooth/bluetoothd         >
Tue 2022-01-18 09:15:54 CET 278994    0    0 SIGSEGV missing      /usr/lib/bluetooth/bluetoothd         >
Tue 2022-01-18 11:57:13 CET 161818 1000 1000 SIGSEGV missing      /usr/bin/pulseaudio                   >
Tue 2022-01-18 11:57:19 CET 336491 1000 1000 SIGABRT missing      /usr/bin/python3.10                   >
Wed 2022-01-19 08:45:31 CET 323223    0    0 SIGSEGV inaccessible /usr/lib/bluetooth/bluetoothd         >
Wed 2022-01-19 13:31:48 CET 330857 1000 1000 SIGILL  present      /usr/share/teams/teams                >
Wed 2022-01-19 13:55:54 CET 426909 1000 1000 SIGQUIT present      /usr/share/teams/resources/app.asar.un>
Thu 2022-01-20 23:18:00 CET    742    0    0 SIGABRT inaccessible /usr/lib/Xorg                         >
Thu 2022-01-20 23:19:45 CET   3085    0    0 SIGABRT inaccessible /usr/lib/Xorg                         >
Thu 2022-01-20 23:20:03 CET   4416    0    0 SIGABRT inaccessible /usr/lib/Xorg                         >
Fri 2022-01-21 09:22:02 CET  52950 1000 1000 SIGQUIT present      /usr/share/teams/resources/app.asar.un>
Fri 2022-01-21 19:53:44 CET   5035    0    0 SIGABRT inaccessible /usr/lib/Xorg                         >
Fri 2022-01-21 19:53:45 CET  52042 1000 1000 SIGSEGV present      /usr/share/teams/teams                >
Fri 2022-01-21 19:53:46 CET  51244 1000 1000 SIGSEGV present      /opt/google/chrome/chrome             >
Fri 2022-01-21 19:56:04 CET    750    0    0 SIGABRT inaccessible /usr/lib/Xorg                         >
Fri 2022-01-21 20:04:52 CET   2007    0    0 SIGABRT inaccessible /usr/lib/Xorg                         >
Fri 2022-01-21 20:10:49 CET  12995    0    0 SIGABRT inaccessible /usr/lib/Xorg

I (have to) use ms-teams for daily work, and it sometimes crashes/hangs, and I have a habbit of issueing a `killall teams`, so the probably explains that entry. Due to occasional troubles w/ my (blue-tooth-connected) headphones, I sometimes have to forcibly restart both pulseaudio (did I mention I do experience issues when using software from lennart?) and bluetoothd

The crashes from Xorg (SIGABRT) do correlate w/ the times when I experienced the beviour I described in my initial post.

Running `coredumpctl info` will output a lot of additional data I cannot make much sense of:

PID: 12995 (Xorg)
UID: 0 (root)
GID: 0 (root)
Signal: 6 (ABRT)
Timestamp: Fri 2022-01-21 20:10:49 CET (1 day 1h ago)
Command Line: /usr/lib/Xorg :0 -seat seat0 -auth /run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch
Executable: /usr/lib/Xorg
Control Group: /system.slice/lightdm.service
Unit: lightdm.service
... # i omitted the module listing
Module Xorg with build-id 54f45e59d2fb69e7a45684977b9a172ae1dd2730
Stack trace of thread 12995:
#0  0x00007f3e3fb97d22 raise (libc.so.6 + 0x3cd22)
#1  0x00007f3e3fb81862 abort (libc.so.6 + 0x26862)
#2  0x000055b529a589b0 OsAbort (Xorg + 0x1539b0)
#3  0x000055b529a5a4f5 FatalError (Xorg + 0x1554f5)
#4  0x000055b529a5feca n/a (Xorg + 0x15aeca)
#5  0x00007f3e3fd3f870 n/a (libpthread.so.0 + 0x13870)

Stack trace of thread 13002:
#0  0x00007f3e3fc5992e epoll_wait (libc.so.6 + 0xfe92e)
#1  0x000055b529a5859b n/a (Xorg + 0x15359b)
#2  0x000055b529a54629 n/a (Xorg + 0x14f629)
#3  0x00007f3e3fd35259 start_thread (libpthread.so.0 + 0x9259)
#4  0x00007f3e3fc595e3 __clone (libc.so.6 + 0xfe5e3)
ELF object binary architecture: AMD x86-64

I also seem to be able to create a dump-file (323 MiB of ELF 64-bit LSB core file according to `file`). However, I do not have an adequate toolset (or expertise) at hand to analyse that.

The `FatalError` part of the stacktrace seems to indicate X11 encountered some bad error condition. Originating from libc if I am not mistaken. Using debug symbols, it might be possible to map this to the function that was called, I believe?

Do you think, further analysing this dump might help to find out about the root-cause?

seth · 2022-01-22 21:23:54

it is not?

"necessarily", but is in case of lightdm (see below)

I suppose I should spend some hours reading journalctl's manpage

sudo journalctl -b > ~/journal.txt

and upload that file somewhere.

Or would it be the underlying mutter-thingy?

GDM, SDDM, LXDM, LightDM, …

Control Group: /system.slice/lightdm.service

So it's lightdm.

The Xorg abort is pretty much nonspeaking, though
(It really just says "aborted for some reason") - if you can reproduce this again, make sure to check the relevant (old) xorg log.

dr1fter · 2022-01-22 21:42:39

and upload that file somewhere.

okay, will do

make sure to check the relevant (old) xorg log.

well, I did, immediately after my X11 session crashed (I checked both log files, including the `.old` one. There were no entries marked as error (according to inline-legend, they should have a `[EE]` prefix). As far as I understood the log files, they just told me about the modules and cfg that was loaded upon session start, and then, that the session was shutdown. As it typically reads, also after e.g. a regular reboot (I am somewhat familiar w/ X11's logs at /var/log, as I had to debug some booting issues some months back :-)).

So it's lightdm.

yes, I also knew I use lightdm (just forgot it is called a DM..)

At any rate, I suppose what I can now do are:

- upload journalctl dump
- check X11 logfiles (including the one at $HOME/.xsession-errors (if I can reproduce the error again)

Thanks a lot so far for your quick and helpful hints

Arch Linux

#1 2022-01-21 21:16:24

starting steam crashes X11-session since yesterday's package-upgrade

#2 2022-01-22 09:01:55

Re: starting steam crashes X11-session since yesterday's package-upgrade

#3 2022-01-22 21:08:57

Re: starting steam crashes X11-session since yesterday's package-upgrade

#4 2022-01-22 21:23:54

Re: starting steam crashes X11-session since yesterday's package-upgrade

#5 2022-01-22 21:42:39

Re: starting steam crashes X11-session since yesterday's package-upgrade

Board footer