Application: plasmashell (6.3.0) ApplicationNotResponding [ANR]: false Qt Version: 6.8.2 Frameworks Version: 6.10.0 Operating System: Linux 6.12.11-200.fc41.x86_64 x86_64 Windowing System: Wayland Distribution: "Fedora Linux 41 (KDE Plasma)" DrKonqi: 6.3.0 [CoredumpBackend] -- Information about the crash: I searched for the "Switch User" menu entry because it isn't listed by default in Kicker's favourites section. When I selected it, a window appeared momentarily, before the shell crashed. Immediately, Dr Konqi appeared. 15s afterward, when it had restarted, I saw a notification that GNOME Abrt had caught it too, and I shall share the URI to its logs when they become available (it's slower to process them than Konqi is). The reporter is unsure if this crash is reproducible. -- Backtrace (Reduced): #5 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44 #6 0x00007faa44e80183 in __pthread_kill_internal (threadid=<optimized out>, signo=6) at pthread_kill.c:78 #7 0x00007faa44e26f9e in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 #8 0x00007faa44e0e942 in __GI_abort () at abort.c:79 #9 0x00007faa4541b91b in qAbort () at /usr/src/debug/qt6-qtbase-6.8.2-2.fc41.x86_64/src/corelib/global/qassert.cpp:49 Reported using DrKonqi
Created attachment 178332 [details] New crash information added by DrKonqi DrKonqi auto-attaching complete backtrace.
(In reply to Roke Julian Lockhart Beedell from comment #0) > I saw a notification that GNOME Abrt had caught it too, and I shall share the URI to its logs when they become available (it's slower to process them than Konqi is). https://bugzilla.redhat.com/show_bug.cgi?id=2325351#c15 is my filing. It appears to have already been reported, which means that although you've got Sentry data, perhaps take a look at their counterpart, too.
(In reply to Roke Julian Lockhart Beedell from comment #0) > The reporter is unsure if this crash is reproducible. I can't report another tonight to demonstrate due to how long debuginfod takes, but I can confirm that it is consistently reproducible. Perhaps relevantly, when switching to the superuser account, I am unable to run `plasmashell`. I see: > QThreadStorage: Thread 0x555a97ea31f0 exited after QThreadStorage {random single-digit integer} destroyed
(In reply to Roke Julian Lockhart Beedell from comment #3) > I can confirm that it is consistently reproducible. After logging out and back in, it no longer reproduces.
I tried to switch the user (even though I'm the only user) just for testing on Debian 13 (unstable repository) with Plasma 6.3.0 and while at first had success as after showing that systemd process log it got me to the login screen preselecting my users and waiting for me to just type my password and enter... After I typed my password and pressed Enter, everything froze and keyboard became unresponsive, including CTRL+ALT+F3, so I had to do a forced reboot from the power button. This problem seems to be the same or very similar with what I've seen with Plasma's beta on KDE Neon as there trying to switch the single user also froze everything. SOFTWARE/OS VERSIONS Linux/KDE Plasma: KDE Plasma Version: 6.3.0 KDE Frameworks Version: 6.10.0 Qt Version: 6.7.2 Kernel Version: 6.12.13-amd64 (64-bit) Graphics Platform: Wayland HARDWARE SPECIFICATIONS Hardware: Laptop Dell Inspiron 5770 (17" 1080p@60Hz screen) CPU: Intel® Core™ i5-8250U CPU @ 1.60GHz GPU 1: Mesa Intel® UHD Graphics 620 (main) GPU 2: AMD Radeon R5 M465 Series RAM: 8 GiB (7.7 GiB usable)
*** Bug 500205 has been marked as a duplicate of this bug. ***
*** Bug 500208 has been marked as a duplicate of this bug. ***
(In reply to Roke Julian Lockhart Beedell from comment #6) Ensure that you don't attempt to switch users if you experience this bug. If the window appears without crashing, you can. If it crashes, don't try to outrun it. (In reply to Roke Julian Lockhart Beedell from comment #7) This doesn't reproduce, so it appears to indicate that the cause is seriously inconsistent. As an example, I have another report that'll be marked as duplicate next which occurs solely in Kicker, but not KRunner!
*** Bug 500209 has been marked as a duplicate of this bug. ***
Should be fixed by https://invent.kde.org/plasma/plasma-workspace/-/commit/1d188e6c285d90c98fdfcbb9b4ab9a1a7334a519, which will be in Plasma 6.4.0.
(In reply to Nate Graham from comment #10) Thank you!
*** Bug 502082 has been marked as a duplicate of this bug. ***
Created attachment 182389 [details] A Demonstration That It Remains In 6.4.0 (In reply to Nate Graham from comment #10) This is marked as a duplicate of https://bugs.kde.org/show_bug.cgi?id=502082#c9, yet it reproduces in 6.4.0: > ~~~ > Operating System: Fedora Linux 42 > KDE Plasma Version: 6.4.0 > KDE Frameworks Version: 6.15.0 > Qt Version: 6.9.1 > Kernel Version: 6.14.11-300.fc42.x86_64 (64-bit) > Graphics Platform: Wayland > Processors: 12 × AMD Ryzen 5 7600X 6-Core Processor > Memory: 32 GiB of RAM (30.4 GiB usable) > Graphics Processor 1: AMD Radeon RX 5700 > Graphics Processor 2: AMD Radeon Graphics > Manufacturer: ASRock > Product Name: X670E Taichi > ~~~ There's nothing of relevance in `journalctl -b -1 -e`: it's mere VS Code log-spam, which is abruptly truncated. I see no events of L1 or 2 with `-p`, and `L3` is filled with irrelevant stack traces for Spectacle due to https://bugs.kde.org/show_bug.cgi?id=505784.
Created attachment 185337 [details] The Output Of `journalctl -b 4265a16e070f49258b97f84afbf6b600` I'll reopen this because https://bugs.kde.org/show_bug.cgi?id=502082#c12 (which is marked as a duplicate of this) still reproduces in 6.4.5. I've attached a log from `journalctl -b 2fc6f8861545419d92b780b7672433e3 > 2fc6f8861545419d92b780b7672433e3.log`, which was a boot which solely reproduced this problem (during which I was forced to utilise SysRq's REI, after which I rebooted via SDDM's GUI). You may want to remove any logs pertaining to https://gitlab.freedesktop.org/drm/amd/-/issues/3248#note_3111855 and https://gitlab.freedesktop.org/drm/amd/-/issues/4266 from it.
What I am adding may or not be useful. I am having lots of switch user freezes after the latest updates. Fedora 42 Nvidia graphics KDE 6.5.1 This has caused me major headaches in the last 24 hrs. Many issues with switch users but the last 24hrs have been a nightmare causing multiple reboots. Looking through my journal logs I see many error messages that are not making sense. I don't know how to use the journal logs properly yet. I have sshd into the system when it has frozen and in one case, sddm_helper_start_wayland was frozen. Killed the process and I was able to use the machine again. I also Just some of the journal messages I am getting after logging into a new session. sddm-helper-start-wayland[23235]: "kwin_scene_opengl: Could not delete render time query because no context is current\n" sddm-greeter-qt6[23264]: file:///usr/share/sddm/themes/01-breeze-fedora/Main.qml:238:17 Parameter "username" is not declared. Injection of parameters into signal handlers is deprecated. Use JavaScript functions with formal parameters instead. sddm-helper-start-wayland[23235]: "QSGContext::initialize: stencil buffer support missing, expect rendering errors\n" sddm-helper-start-wayland[23235]: "QSGContext::initialize: depth buffer support missing, expect rendering errors\n" When the system was locked, I have hundereds of this message. kwin_wayland[18168]: kwin_wayland_drm: Failed to create a framebuffer: Invalid argument And a whole series of these with the last cfg_ being different. plasmashell[18355]: file:///usr/share/plasma/shells/org.kde.plasma.desktop/contents/configuration/ConfigurationContainmentAppearance.qml: Setting initial properties failed: ConfigurationContainmentAppearance does not have a property called cfg_labelWidth I also have these but not sure if they are related or just another issue. kconf_update[18512]: kf.config.kconf_update: /usr/share/kconf_update/webenginepart.upd defined Version=5 but Version=6 was expected kconf_update[18512]: kf.config.kconf_update: /usr/share/kconf_update/filepicker.upd defined Version=5 but Version=6 was expected kded6[18330]: kf.dbusaddons: The kded module name "oom-notifier" is invalid! kded6[18330]: QDBusObjectPath: invalid path "/modules/oom-notifier" kded6[18330]: kf.dbusaddons: The kded module name "kded_plasma-welcome" is invalid! kded6[18330]: QDBusObjectPath: invalid path "/modules/kded_plasma-welcome" In one of the many crashes where the screen and keyboard were not responsive to changing ttys, I killed startplasma-wayland of one of the sessions and I was able to get back into the computer. One of the user sessions related to the startplasma-wayland was terminated. Still better than a hard reboot. I am also getting a message about xcb and xdg which are not installed. Again, don't know if they are related or not. I don't have a gnome desktop installed on this system.
(In reply to Robin Laing from comment #15) I don't believe that one should be able to switch TTYs when this bug impacts them. Additionally, adhering to the diagnostic process detailed at https://www.reddit.com/r/archlinux/comments/1bo21lu/comment/kwm7unx/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button, and posting the results to https://discuss.kde.org/new-topic, shall likely yield better results. To me, this looks like the usual NVIDIA incompatibilities after a new package selection update (likely a kernel update). > I am also getting a message about xcb and xdg which are not installed. > Again, don't know if they are related or not. This tends to merely indicate a problem with the compositor, or available permissions. It's poorly-worded, per https://forum.endeavouros.com/t/should-i-be-using-run0-instead-of-sudo/69141/70?u=rokejulianlockhart.
Comment on attachment 182389 [details] A Demonstration That It Remains In 6.4.0 Since invoking it via Kickoff 6.5.2, then SysRq + RE'ing when this problem reproduced, [^1] `qdbus-qt6 --system org.freedesktop.DisplayManager /org/freedesktop/DisplayManager/Seat0 org.freedesktop.DisplayManager.Seat.SwitchToGreeter`, now works… [^2] [^1]: https://github.com/abrt/abrt/issues/1679#issue-3633163156 [^2]: https://www.reddit.com/r/kde/comments/i94khf/comment/npb10wj
(In reply to Roke Julian Lockhart Beedell from comment #16) > (In reply to Robin Laing from comment #15) > > I don't believe that one should be able to switch TTYs when this bug impacts > them. Additionally, adhering to the diagnostic process detailed at > https://www.reddit.com/r/archlinux/comments/1bo21lu/comment/kwm7unx/ > ?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=s > hare_button, and posting the results to https://discuss.kde.org/new-topic, > shall likely yield better results. To me, this looks like the usual NVIDIA > incompatibilities after a new package selection update (likely a kernel > update). > Switched from SDDM to GDM and now if I have an issue, I can switch to a terminal and prevent a total system lockup. That is where being able to switch to a tty is a benefit. A hard reboot is not a great way to get a system to respond. I have not had time to test much since the change.
(In reply to Robin Laing from comment #18) > Switched from SDDM to GDM and now if I have an issue, I can switch to a > terminal and prevent a total system lockup. That is where being able to > switch to a tty is a benefit. You don't quite need to “hard-reboot” (as in, via your motherboard). SysRq REISUB is sufficient. > A hard reboot is not a great way to get a > system to respond. I have not had time to test much since the change. If you can share any relevant JournalCtl logs when this occurs, that might be of use, since it'll show what's common between SDDM and GDM in this regard.
Created attachment 187183 [details] jounrnal logs from a blackscreen login Don't know what "SysRq REISUB" is. All I know is that the keyboard was useless. I agree with the journal logs and I am still trying to learn how to use journalctl. I changed to gdm so I am now getting gnome errors in my logs. I do feel that some of my issues are related to graphic card memory usage. Things work better if I can minimize graphic memory usage. Tonight switched user from my regular account to the "shopping" account and ended up with a black screen. ssh into the system to kill that session allowed a second attempt to work. Attaching the relevant logs from that failed attempt. After killing the user "loginctl kill-user shopping" the next login worked.
(In reply to Robin Laing from comment #20) Thanks for the logs. > Created attachment 187183 [details] > jounrnal logs from a blackscreen login > > Don't know what "SysRq REISUB" is. All I know is that the keyboard was > useless. I meant that to recover from this state, you need to enable the kernel's recovery method, with `run0 sysctl -w kernel.sysrq=1`, per https://fedoraproject.org/w/index.php?title=QA/Sysrq&oldid=666802#How_do_I_enable_the_magic_SysRq_key?:~:text=it%20by%20doing.-,sysctl%20%2Dw%20kernel.sysrq=1,-The%20value%20of. The documentation immediately after that cited section explains how to utilise it when you get stuck in this state. However, to summarise, you need to hold Alt + Print Screen + R, E, I, S, U, B.
(In reply to Roke Julian Lockhart Beedell from comment #21) > (In reply to Robin Laing from comment #20) > > Thanks for the logs. > > > Created attachment 187183 [details] > > jounrnal logs from a blackscreen login > > > > Don't know what "SysRq REISUB" is. All I know is that the keyboard was > > useless. > > I meant that to recover from this state, you need to enable the kernel's > recovery method, with `run0 sysctl -w kernel.sysrq=1`, per > https://fedoraproject.org/w/index.php?title=QA/ > Sysrq&oldid=666802#How_do_I_enable_the_magic_SysRq_key?:~: > text=it%20by%20doing.-,sysctl%20%2Dw%20kernel.sysrq=1,-The%20value%20of. The > documentation immediately after that cited section explains how to utilise > it when you get stuck in this state. However, to summarise, you need to hold > Alt + Print Screen + R, E, I, S, U, B. Thank you. Will read up on that. Not sure if that would have worked but will make a note to try it if I have an issue again. Keyboard seemed unresponsive at the time.
Just a note. I just put a new video card into this machine since I was maxing out my video ram all the time. What I noticed is the amount of video ram used for each plasma session. It is over a gig with this video card for each session. Since I usually had two sessions open on this computer, I was maxing out my ram on the old card that had only 2Gig of Vram. If I have an issue again, I will report it. I don't know if a shortage of vram could cause the issues I have seen but I thought I would pass on the information.