Created attachment 177405 [details] gbp backtrace STEPS TO REPRODUCE lock and unlock OBSERVED RESULT Plasmashell bar disappears SOFTWARE/OS VERSIONS Operating System: Debian GNU/Linux 12 KDE Plasma Version: 6.2.5 KDE Frameworks Version: 6.8.0 Qt Version: 6.7.2 Kernel Version: 6.12.6-amd64 (64-bit) Graphics Platform: Wayland Processors: 14 × Intel® Core™ Ultra 7 165U Memory: 62.3 GiB of RAM Graphics Processor: Mesa Intel® Graphics ADDITIONAL INFORMATION
Created attachment 177406 [details] journald logs
Does the desktop turn black too?
🐛🧹 ⚠️ This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information, then set the bug status to REPORTED. If there is no change for at least 30 days, it will be automatically closed as RESOLVED WORKSFORME. For more information about our bug triaging procedures, please read https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging. Thank you for helping us make KDE software even better for everyone!
🐛🧹 This bug has been in NEEDSINFO status with no change for at least 30 days. Closing as RESOLVED WORKSFORME.
Reopening this because I think it's my bug, although I don't see this every time the screen locks, only sometimes. It also started for me at some point in the last few months - I've been hoping to narrow down the cause before reporting it but I haven't had any luck, so I decided to report it today. It seems to happen more often when I have recently plugged in / unplugged my USB-C monitor. I usually use one screen exclusively, so the monitor becomes active automatically when plugging it in, while turning the laptop screen off, and vice versa, when I unplug the monitor. I also see an issue sometimes where the monitor will not turn off despite being locked, and auto-off being configured. I think it's possible this is happening when this issue occurs, but I haven't been able to confirm this yet. Note that I also see this other issue, which might be related: https://bugs.kde.org/show_bug.cgi?id=491699 > Does the desktop turn black too? Yes it does. The plasma-plasmashell service continues running, though. There's no crash involved here. My logs look very similar to the reporter's.
Incidentally, this should probably be moved to Session Management? Or maybe generic-crash? Although it's not a true crash, the effect is actually worse than a crash because at least with a crash systemd will restart plasmashell on most systems. My system: Operating System: Arch Linux KDE Plasma Version: 6.3.4 KDE Frameworks Version: 6.12.0 Qt Version: 6.9.0 Kernel Version: 6.14.2-arch1-1 (64-bit) Graphics Platform: Wayland Graphics Processor: AMD Radeon Graphics
It's fine where it is; this is an issue where the containments get misplaced.
Putting needsinfo again: in order to act on it, would be useful a complete backtrace
I'm happy to try to provide a backtrace if you can provide some guidance as to (a) what a useful backtrace looks like in this case, and (b) how I can get one. Since this isn't a crash, it isn't obvious to me what a backtrace will show. For all I know plasmashell is running normally and simply incorrectly placed the desktop off screen somewhere. Can I just core dump the running process with gdb next time the issue occurs and take a backtrace from that? Also, note that since this issue doesn't occur reliably for me (when it starts to happen it's pretty frequent, but I haven't seen it in a while), this could take a while to achieve.
This should do it: "gdb attach $(pidof plasmashell)" Then press "c" if it asks you if you want to see more. Then enter "bt". Then press "c" again if needed. Then copy-and-paste the result here.
Created attachment 182244 [details] backtrace of plasmashell with all threads Okay, here's a backtrace captured as suggested by Nate. As I kind of expected, Plasmashell isn't actively doing anything, and so the backtrace just shows the main thread what appears to be a poll waiting state. #0 0x00007f19ad2ade22 in ??? () at /usr/lib/libc.so.6 #1 0x00007f19ad2a1fda in ??? () at /usr/lib/libc.so.6 #2 0x00007f19ad2a2024 in ??? () at /usr/lib/libc.so.6 #3 0x00007f19ad31c5a6 in ppoll () at /usr/lib/libc.so.6 #4 0x00007f19ac5b6e04 in ??? () at /usr/lib/libglib-2.0.so.0 #5 0x00007f19ac5b6ee5 in g_main_context_iteration () at /usr/lib/libglib-2.0.so.0 #6 0x00007f19adbcd59d in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib/libQt6Core.so.6 #7 0x00007f19ad965376 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib/libQt6Core.so.6 #8 0x00007f19ad95d159 in QCoreApplication::exec() () at /usr/lib/libQt6Core.so.6 #9 0x00005586b0e9070a in ??? () #10 0x00007f19ad2376b5 in ??? () at /usr/lib/libc.so.6 #11 0x00007f19ad237769 in __libc_start_main () at /usr/lib/libc.so.6 #12 0x00005586b0e90c45 in ??? () I also printed the backtrace for every thread just in case that's somehow helpful, and attached it. Let me know if there's something else I can provide.
Does this happen on X11 too? Or only on Wayland?
As I don't use X11 anymore, I can't answer that easily. I'd happily switch for a one-off test, but as I mentioned previously, I'm only able to reproduce this occasionally, and recently I haven't seen it during a lock/unlock at all, only when switching screens. (Happy to file a separate bug if you think that makes it unrelated.) Maybe Frederico could indicate whether they still see the bug on every unlock? Is there a way to tag this bug so that it doesn't close itself despite being NEEDSINFO? Since multiple people have seen the issue, it shouldn't be closed as WORKSFORME. I understand more information might be needed to fix the problem, but it's unfortunate if the bug gets automatically closed just because the original reporter isn't able to respond.
If Federico never responds, we should let other people open new bug reports, since their issues may well be different. Until it's determined that they're the same thing, they need to be triaged separately.