SUMMARY Sometimes when I press the volume down combination (fn+f2) plasma logs out. It happened only three times so far, the volume dialog shows, and then it kicks me back to SDDM. STEPS TO REPRODUCE 1. Press volume down combination. OBSERVED RESULT Plasma logs out. EXPECTED RESULT Volume going down. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Manjaro/Plasma 5 KDE Plasma Version: 5.23.4 KDE Frameworks Version: 5.88.0 Qt Version: 5.15.2 ADDITIONAL INFORMATION This started after the latest Majaro package update.
Are you using X11 or Wayland?
(In reply to Nicolas Fella from comment #1) > Are you using X11 or Wayland? X11, Also it doesn't seem to be exclusive to volume down, it happened with volume up too.
Sounds like the X server crashed. Can you see if there's an xorg backtrace using the `coredumpctl` utility?
(In reply to Nate Graham from comment #3) > Sounds like the X server crashed. Can you see if there's an xorg backtrace > using the `coredumpctl` utility? Something like this?: Thu 2021-12-23 19:08:19 637 0 0 SIGABRT missing /usr/lib/Xorg Unfortunately, that's the latest one I can find because I haven't used Plasma for a while (because it crashes) and it says the source file is missing so I guess we have to recreate the crash. So I'll switch back to Plasma and wait for another crash to happen. Is that ok?
Sounds good! Change the status back to REPORTED once you've got one.
(In reply to Nate Graham from comment #5) > Sounds good! Change the status back to REPORTED once you've got one. Thu 2022-01-13 14:01:45 1043 1000 1000 SIGSEGV present /usr/lib/baloo_file Thu 2022-01-13 14:03:45 671 0 0 SIGABRT inaccessible /usr/lib/Xorg Thu 2022-01-13 14:03:47 960 1000 1000 SIGSEGV present /usr/bin/kwin_x11 It crashed again as planned however it says `inaccessible` for the file in `coredumpctl` anyways, here is the files: /var/log/Xorg.0.log.old: http://ix.io/3M3V /var/log/Xorg.0.log: http://ix.io/3M3X /var/log/Xorg.1.log.old: http://ix.io/3M3Y /var/log/Xorg.1.log: empty
I don't know what "inaccessible" means here, but we need that xorg backtrace to determine if the X11 server crash is our fault.
X11 is running as root, so it's quite unsurprising that its crashdump can't be accessed as an regular user
Oh, so `sudo coredumpctl` might do it, then.
Ok here is the output of `sudo coredumpctl` is there anything else I should send? Thu 2022-01-13 14:01:45 1043 1000 1000 SIGSEGV present /usr/lib/baloo_file Thu 2022-01-13 14:03:45 671 0 0 SIGABRT present /usr/lib/Xorg Thu 2022-01-13 14:03:47 960 1000 1000 SIGSEGV present /usr/bin/kwin_x11
Now you need to get a backtrace from that coredump, using `sudo coredumpctl debug 671`.
Is this it?: http://ix.io/3M6y
The interesting part is #0 0x00007f867c8dad22 raise (libc.so.6 + 0x3cd22) #1 0x00007f867c8c4862 abort (libc.so.6 + 0x26862) #2 0x000055e8b3b3fa00 OsAbort (Xorg + 0x153a00) #3 0x000055e8b3b41545 FatalError (Xorg + 0x155545) #4 0x000055e8b3b46f1a n/a (Xorg + 0x15af1a) #5 0x00007f867ca82870 __restore_rt (libpthread.so.0 + 0x13870) #6 0x000055e8b3bd1448 n/a (Xorg + 0x1e5448) #7 0x000055e8b3a793c5 n/a (Xorg + 0x8d3c5) #8 0x000055e8b3a79a0c n/a (Xorg + 0x8da0c) #9 0x000055e8b3a7ac03 n/a (Xorg + 0x8ec03) #10 0x000055e8b3af8d9b n/a (Xorg + 0x10cd9b) #11 0x000055e8b3b32804 XkbHandleActions (Xorg + 0x146804) #12 0x000055e8b3bc9082 n/a (Xorg + 0x1dd082) #13 0x000055e8b3b20cce n/a (Xorg + 0x134cce) #14 0x000055e8b3b3a454 n/a (Xorg + 0x14e454) #15 0x000055e8b3b3a762 WaitForSomething (Xorg + 0x14e762) #16 0x000055e8b3a2887b n/a (Xorg + 0x3c87b) #17 0x00007f867c8c5b25 __libc_start_main (libc.so.6 + 0x27b25) #18 0x000055e8b3a2979e _start (Xorg + 0x3d79e) Since this doesn't contain debug symbols and your distribution does not provide those there's still not much we can do with it, other than semi-educatedly guessing that it's probably not Plasma's fault
Looks like https://gitlab.freedesktop.org/xorg/xserver/-/issues/1261
Ooh, nice find. It does indeed.
*** Bug 448413 has been marked as a duplicate of this bug. ***