STEPS TO REPRODUCE Refer to video attached. OBSERVED RESULT Entries should be increased and session stay alive. EXPECTED RESULT Session crashes SOFTWARE/OS VERSIONS Operating System: openSUSE Tumbleweed 20220120 KDE Plasma Version: 5.23.5 KDE Frameworks Version: 5.90.0 Qt Version: 5.15.2 Kernel Version: 5.16.1-1-default (64-bit) Graphics Platform: Wayland Processors: 8 × 11th Gen Intel® Core™ i7-11370H @ 3.30GHz Memory: 15,4 GiB of RAM Graphics Processor: Mesa Intel® Xe Graphics ADDITIONAL INFORMATION Using arrows to change values works fine, and even entering text works fine as long as you previously highlighted it by using the arrows (not placing mouse cursor and clicking)
Video recording here: https://drive.google.com/file/d/1XlX_oLBCCwdN599YCJu4-b2evCn-VSoO/view?usp=sharing
your video is not public
Created attachment 145725 [details] reproduced
(In reply to Patrick Silva from comment #2) > your video is not public Sorry, should be fixed now with the attachment.
I tried with Wayland and X and I couldn't reproduce the issue on Neon Unstable. Can you try reproducing the issue with a live session or a VM with a vanilla install? Are you using any kind of custom font or theme?
(In reply to guimarcalsilva from comment #5) > I tried with Wayland and X and I couldn't reproduce the issue on Neon > Unstable. Can you try reproducing the issue with a live session or a VM with > a vanilla install? Are you using any kind of custom font or theme? This is so weird. I didn't even need a live environment, just creating another user proves that this is somehow user related, as I don't see this on a brand new account. I do use a custom font and custom scaling, but even by resetting those I still have the problem on my user. last entries in journalctl --user (after the crash was reproduced): gen 22 18:44:05 skikk plasmashell[6484]: trying to show an empty dialog gen 22 18:44:10 skikk plasmashell[6484]: The Wayland connection experienced a fatal error: Resource temporarily unavailable gen 22 18:44:10 skikk kded5[6465]: Service "org.kde.StatusNotifierHost-6484" unregistered Is there a command to run in order to provide more detailed logs? Thanks PS on X11 it's fine even with my user
I'm suspecting a Global Theme I had previously installed and removed, but somehow some parts stick around and show up in Discover as proposed updates. Ant-Dark. Man theming is seriously broken and can break havoc in KDE (an entirely different story). I'll try to repro inside a VM.
(In reply to andrea.ippo from comment #7) > I'm suspecting a Global Theme I had previously installed and removed, but > somehow some parts stick around and show up in Discover as proposed updates. > Ant-Dark. Man theming is seriously broken and can break havoc in KDE (an > entirely different story). > > I'll try to repro inside a VM. P.s. after removing that theme I've reapplied Breeze dark global theme. Maybe worth trying to reproduce by doing that, I dunno.
Can you attach a backtrace of the crash? See https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports
(In reply to Nate Graham from comment #9) > Can you attach a backtrace of the crash? See > https://community.kde.org/Guidelines_and_HOWTOs/Debugging/ > How_to_create_useful_crash_reports Hello Nate, I don't understand for which lib* package I should get debuginfo packages, as the log I previously pasted doesn't mention anything like that. Could you please help? Thanks
plasma packages are fine to start with, and we can go from there. Side note: Even a backtrace with no symbols is more usefu than none at all. It's not helpful for determining where exactly the bug is, but it can sometimes be used to identify that the crash is the same as a previously-reported one.
(In reply to Nate Graham from comment #11) > plasma packages are fine to start with, and we can go from there. > > Side note: Even a backtrace with no symbols is more usefu than none at all. > It's not helpful for determining where exactly the bug is, but it can > sometimes be used to identify that the crash is the same as a > previously-reported one. Hello Nate, thanks for the info, I followed opensuse's guide for fetching traces and this is what I could get by doing: gdb /usr/bin/plasmashell Starting program: /usr/bin/plasmashell [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". [New Thread 0x7ffff0de3640 (LWP 4900)] [New Thread 0x7fffe44cf640 (LWP 4902)] [New Thread 0x7fffe3cce640 (LWP 4903)] [New Thread 0x7fffe34cd640 (LWP 4904)] [New Thread 0x7fffe2ccc640 (LWP 4905)] [New Thread 0x7fffe24cb640 (LWP 4906)] [New Thread 0x7fffe1cca640 (LWP 4907)] [New Thread 0x7fffe14c9640 (LWP 4908)] [New Thread 0x7fffe0c74640 (LWP 4909)] [New Thread 0x7fffc3fff640 (LWP 4910)] [Thread 0x7fffe0c74640 (LWP 4909) exited] [Thread 0x7fffc3fff640 (LWP 4910) exited] [New Thread 0x7fffc3fff640 (LWP 4911)] [New Thread 0x7fffe0c74640 (LWP 4912)] [New Thread 0x7fffb7916640 (LWP 4913)] [Thread 0x7fffb7916640 (LWP 4913) exited] [Thread 0x7fffe0c74640 (LWP 4912) exited] [New Thread 0x7fffe0c74640 (LWP 4914)] [New Thread 0x7fffb7916640 (LWP 4915)] [New Thread 0x7fffb6b63640 (LWP 4916)] [New Thread 0x7fffb4877640 (LWP 4917)] [Detaching after fork from child process 4918] [Thread 0x7fffb4877640 (LWP 4917) exited] [New Thread 0x7fffb4877640 (LWP 4920)] [New Thread 0x7fffacb40640 (LWP 4921)] [New Thread 0x7fffa3fff640 (LWP 4922)] [New Thread 0x7fffa14de640 (LWP 4926)] [New Thread 0x7fffa0c8d640 (LWP 4927)] [Thread 0x7fffa14de640 (LWP 4926) exited] [Thread 0x7fffa0c8d640 (LWP 4927) exited] [New Thread 0x7fffa0c8d640 (LWP 4928)] [New Thread 0x7fffa14de640 (LWP 4929)] [New Thread 0x7fffae794640 (LWP 4930)] [New Thread 0x7fffadf93640 (LWP 4931)] [New Thread 0x7fffad792640 (LWP 4932)] [New Thread 0x7fff87fff640 (LWP 4933)] [New Thread 0x7fffb5165640 (LWP 4934)] [Detaching after fork from child process 4935] [New Thread 0x7fff84ffe640 (LWP 4942)] [Detaching after fork from child process 4948] [New Thread 0x7fffaffb8640 (LWP 4950)] [New Thread 0x7fffaf765640 (LWP 4951)] [New Thread 0x7fff6e3ff640 (LWP 4952)] [Detaching after fork from child process 4953] [Detaching after fork from child process 4955] [Detaching after fork from child process 4957] [Thread 0x7fff87fff640 (LWP 4933) exited] [Thread 0x7fffadf93640 (LWP 4931) exited] [Thread 0x7fffa0c8d640 (LWP 4928) exited] [Thread 0x7fffb7916640 (LWP 4915) exited] [Thread 0x7fffad792640 (LWP 4932) exited] [Thread 0x7fffae794640 (LWP 4930) exited] [Thread 0x7fffa14de640 (LWP 4929) exited] [Thread 0x7fffe0c74640 (LWP 4914) exited] [Thread 0x7fff6e3ff640 (LWP 4952) exited] [Thread 0x7fffaf765640 (LWP 4951) exited] [Thread 0x7fffaffb8640 (LWP 4950) exited] [Thread 0x7fff84ffe640 (LWP 4942) exited] [Thread 0x7fffb5165640 (LWP 4934) exited] [Thread 0x7fffa3fff640 (LWP 4922) exited] [Thread 0x7fffacb40640 (LWP 4921) exited] [Thread 0x7fffb4877640 (LWP 4920) exited] [Thread 0x7fffb6b63640 (LWP 4916) exited] [Thread 0x7fffc3fff640 (LWP 4911) exited] [Thread 0x7fffe14c9640 (LWP 4908) exited] [Thread 0x7fffe1cca640 (LWP 4907) exited] [Thread 0x7fffe24cb640 (LWP 4906) exited] [Thread 0x7fffe2ccc640 (LWP 4905) exited] [Thread 0x7fffe34cd640 (LWP 4904) exited] [Thread 0x7fffe44cf640 (LWP 4902) exited] [Thread 0x7ffff0de3640 (LWP 4900) exited] [Thread 0x7ffff311a980 (LWP 4891) exited] [Inferior 1 (process 4891) exited with code 01] This last line is logged when plasmashell crashes. It also happens when selecting the number in the Timeout for action popup selection. I feel like this is not useful tho. Please let me know how I can provide logs with a line number, an exception, etc...
Indeed it's not useful, because there's no backtrace. :) When plasma crashes, you need to type `bt` in the GDB prompt. However I see now that you said the whole session crashed; if so that means that kwin_wayland is the thing that crashed, not plasmashell. So we would need a backtrace of the last kwin_wayland crash. you can use `coredumpctl` for this; see https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports#Retrieving_a_backtrace_using_coredumpctl
(In reply to Nate Graham from comment #13) > Indeed it's not useful, because there's no backtrace. :) When plasma > crashes, you need to type `bt` in the GDB prompt. > > However I see now that you said the whole session crashed; if so that means > that kwin_wayland is the thing that crashed, not plasmashell. So we would > need a backtrace of the last kwin_wayland crash. you can use `coredumpctl` > for this; see > https://community.kde.org/Guidelines_and_HOWTOs/Debugging/ > How_to_create_useful_crash_reports#Retrieving_a_backtrace_using_coredumpctl Hi again Pointiest, actually the session does not crash, all running apps stay alive and usable (Krunner as well). I will update the title to reflect this. Now to the bt command, when I type it after attaching gdb to the plasmashell process and triggering the crash of plasmashell, it only says: `No stack.` Hereafter the last part of gdb until the crash + backtrace. Could you please advise further? Thanks! [Thread 0x7fffc2ffd640 (LWP 9911) exited] [Thread 0x7fffbb7fe640 (LWP 9908) exited] [Thread 0x7fffc3fff640 (LWP 9907) exited] [Thread 0x7fffd882c640 (LWP 9906) exited] [Thread 0x7fffd902d640 (LWP 9905) exited] [Thread 0x7fffd982e640 (LWP 9904) exited] [Thread 0x7fffda02f640 (LWP 9903) exited] [Thread 0x7fffecaa8640 (LWP 9902) exited] [Thread 0x7fffefe75640 (LWP 9901) exited] [Thread 0x7ffff0676640 (LWP 9900) exited] [Thread 0x7ffff0e77640 (LWP 9899) exited] [Thread 0x7ffff3117980 (LWP 9860) exited] [Inferior 1 (process 9860) exited with code 01] (gdb) backtrace No stack. (gdb)
Sounds like it's exiting rather than crashing. Thanks.
(In reply to Nate Graham from comment #15) > Sounds like it's exiting rather than crashing. Thanks. Hello Nate, please let me know if I can help in any other way by providing other logs, config files, you name it.
At this point it's beyond my debugging ability, so someone else will have to take over.
Can no longer reproduce with 5.25.2, can be closed as far as I'm concerned.