SUMMARY So, I know that this is not quite a full bug report with a nice backtrace yet, but I need some help to get there because I'm running out of ideas. Here is what I got so far: - This bug is hardware-specific. I get it on one machine (desktop using an AMD Ryzen 5 5600G's integrated graphics, connected to a Philips 272B7QPTK screen) but not on another (MSI Alpha A4DEK laptop using an AMD Ryzen 7 4800H + RX 5600M hybrid setup + unknown screen model), with otherwise similar hardware configuration. - This bug is related to GPU or screen power management. In the default powerdevil configuration, where the screen automatically turns off, when I wake up the computer I face the message telling me that I need to log in to a VT and run "loginctl unlock-session 2" to unlock the screen. And in journalctl, it says that kscreenlocker_greet segfaulted. If I disable screen poweroff, then the bug never happens, however long I keep the login screen on. I sometimes manage to reproduce the bug by running "sleep 10 && kscreen-doctor --dpms off" on one terminal and "/usr/lib/kscreenlocker_greet --testing" on another terminal, but not always, and it's not clear to me what are the precise circumstances that cause it to trigger. This makes it harder for me to analyze the bug further. - This bug is not related to libddc. Although there were tons of promising libddc warnings/errors in the journalctl logs, turning off libddc as directed by the powerdevil readme silences the warnings but does not stop the crashes. Along the way, I also tried to increase the powerdevil log verbosity as directed in the powerdevil readme, but that did not turn up anything useful. - This bug comes from some sort of memory corruption. One time I managed to get /usr/lib/kscreenlocker_greet to reproduce the bug under GDB, which gave me a stack trace where the code was attempting to dereference a QWeakPointer with a target address of 0x6d1 or something blatantly invalid like that. I hoped to find out who overwrote the address of that pointer with rr, but the bug does not reproduce under either rr or valgrind. That being said, valgrind does report many out-of-bounds issues in KSVG, but judging by the very different memory addresses and the fact that these errors are reported even if the screen does not turn off, this seems to be an unrelated issue. STEPS TO REPRODUCE 1. Get the same hardware as I do? 2. Set "Shutdown screen after..." to anything other than "Never" in powerdevil. 3. Wait for screen to lock and turn off, maybe some extra time (it seems the crash is not always right at the point where the screen turns off). OBSERVED RESULT Wiggle mouse, face a kscreenlocker crash report, need to switch to VT to get back to my desktop. EXPECTED RESULT Screen locker shows up normally and lets me unlock my session without dirty VT tricks. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 6.3.2 KDE Frameworks Version: 6.11.0 Qt Version: 6.8.2 Kernel Version: 6.13.5-arch1-1 (64-bit) Graphics Platform: Wayland Processors: 12 × AMD Ryzen 5 5600G with Radeon Graphics Memory: 62.2 Gio of RAM Graphics Processor: AMD Radeon Graphics ADDITIONAL INFORMATION I reliably get a plasma shell crash report dialog on the same system when resuming from sleep. I do not know if this is related or not.
...ah, sorry, when I wrote "otherwise similar hardware configuration above", I meant "otherwise similar **software** configuration". I switched both to Arch recently and configured them in a very similar fashion, basically taking my notes from setting up one machine to set up the other.
Another piece of data that may or may not be related: I just thought about turning the screen off via the hardware power button (instead of DPMS), leaving it off for a while, then turning it back on, while the lock screen is active. This did not crash the lock screen. But after logging back in, I got a plasmashell crash window similar to the ones I reliably get when resuming the machine from sleep... I only left the screen off for a short while (~15s?) though, so I'm going to try doing this over a longer period of time, to see if it does eventually crash the lockscreen or not.
If something crashed, we do need a backtrace of it so we can figure out what's going on. Can you please attach a backtrace of the crash using the coredumpctl command-line program, as detailed in https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports#Retrieving_a_backtrace_using_coredumpctl? There should be some coredumps, since you've seen the crash reporter appear. Thanks!
Most of the coredumps are from plasmashell from resuming from sleep or power-cycling the monitor, which I suspect to be a different issue. I should probably create a different bug report for those crashes. But if you prefer, I can add some of them here. However, there are actually a few that I missed from kscreenlocker_greet. Here is the most recent one: Core was generated by `/usr/lib/kscreenlocker_greet --testing'. Program terminated with signal SIGSEGV, Segmentation fault. #0 std::__atomic_base<int>::load (this=0xf5, __m=std::memory_order::relaxed) at /usr/include/c++/14.2.1/bits/atomic_base.h:499 499 __glibcxx_assert(__b != memory_order_acq_rel); [Current thread is 1 (Thread 0x777d1ef7fa80 (LWP 70768))] (gdb) bt #0 std::__atomic_base<int>::load (this=0xf5, __m=std::memory_order::relaxed) at /usr/include/c++/14.2.1/bits/atomic_base.h:499 #1 QAtomicOps<int>::loadRelaxed<int> (_q_value=<error reading variable: Cannot access memory at address 0xf5>) at /usr/include/qt6/QtCore/qatomic_cxx11.h:202 #2 QBasicAtomicInteger<int>::loadRelaxed (this=0xf5) at /usr/include/qt6/QtCore/qbasicatomic.h:36 #3 QWeakPointer<QObject>::internalData (this=0x633b9795f328) at /usr/include/qt6/QtCore/qsharedpointer_impl.h:752 #4 QPointer<QObject>::data (this=<optimized out>, this=<optimized out>) at /usr/include/qt6/QtCore/qpointer.h:75 #5 QPointer<QObject>::operator QObject* (this=<optimized out>, this=<optimized out>) at /usr/include/qt6/QtCore/qpointer.h:83 #6 PlasmaQuick::SharedQmlEngine::rootObject (this=0x633b97d58d60) at /usr/src/debug/libplasma/libplasma-6.3.2/src/plasmaquick/sharedqmlengine.cpp:226 #7 0x0000777d27fa3f06 in PlasmaQuick::QuickViewSharedEngine::rootObject (this=<optimized out>) at /usr/src/debug/libplasma/libplasma-6.3.2/src/plasmaquick/quickviewsharedengine.cpp:187 #8 0x0000633b5790dec3 in ScreenLocker::UnlockApp::markViewsAsVisible (this=0x7ffce6854e60, view=<optimized out>) at /usr/src/debug/kscreenlocker/kscreenlocker-6.3.2/greeter/greeterapp.cpp:450 #9 0x0000777d259a2f4a in QObject::event (this=0x7ffce6854e60, e=0x777cc4552570) at /usr/src/debug/qt6-base/qtbase/src/corelib/kernel/qobject.cpp:1418 #10 0x0000777d25955b00 in QCoreApplication::notifyInternal2 (receiver=0x7ffce6854e60, event=event@entry=0x777cc4552570) at /usr/src/debug/qt6-base/qtbase/src/corelib/kernel/qcoreapplication.cpp:1172 #11 0x0000777d25955edc in QCoreApplication::sendEvent (receiver=<optimized out>, event=0x777cc4552570) at /usr/src/debug/qt6-base/qtbase/src/corelib/kernel/qcoreapplication.cpp:1612 #12 QCoreApplicationPrivate::sendPostedEvents (receiver=0x0, event_type=0, data=0x633b9723fca0) at /usr/src/debug/qt6-base/qtbase/src/corelib/kernel/qcoreapplication.cpp:1946 #13 0x0000777d25bc859c in QCoreApplication::sendPostedEvents (receiver=0x0, event_type=0) at /usr/src/debug/qt6-base/qtbase/src/corelib/kernel/qcoreapplication.cpp:1800 #14 postEventSourceDispatch (s=s@entry=0x633b97244700) at /usr/src/debug/qt6-base/qtbase/src/corelib/kernel/qeventdispatcher_glib.cpp:246 #15 0x0000777d23d06104 in g_main_dispatch (context=0x777d18000f00) at ../glib/glib/gmain.c:3398 #16 0x0000777d23d69d57 in g_main_context_dispatch_unlocked (context=0x777d18000f00) at ../glib/glib/gmain.c:4249 #17 g_main_context_iterate_unlocked.isra.0 (context=context@entry=0x777d18000f00, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../glib/glib/gmain.c:4314 #18 0x0000777d23d05535 in g_main_context_iteration (context=0x777d18000f00, may_block=1) at ../glib/glib/gmain.c:4379 #19 0x0000777d25bc575d in QEventDispatcherGlib::processEvents (this=0x633b97245b40, flags=...) at /usr/src/debug/qt6-base/qtbase/src/corelib/kernel/qeventdispatcher_glib.cpp:399 #20 0x0000777d259606a6 in QEventLoop::processEvents (this=0x7ffce6854b80, flags=...) at /usr/src/debug/qt6-base/qtbase/src/corelib/kernel/qeventloop.cpp:103 #21 QEventLoop::exec (this=0x7ffce6854b80, flags=...) at /usr/src/debug/qt6-base/qtbase/src/corelib/kernel/qeventloop.cpp:185 #22 0x0000777d259591d6 in QCoreApplication::exec () at /usr/src/debug/qt6-base/qtbase/src/corelib/global/qflags.h:74 #23 0x0000633b5790c6b5 in main (argc=<optimized out>, argv=<optimized out>) at /usr/src/debug/kscreenlocker/kscreenlocker-6.3.2/greeter/main.cpp:207 As you can see, it looks like some QObject got its internal state corrupted, to the point of believing that 0xf5 is a valid userspace pointer. What I did not manage to figure out so far is, who overwrote that memory and why. It would have been great if the crash reproduced under rr or valgrind...
Oh and by the way, the experiment outcome is that turning the screen off and back on using the hardware power button does not crash the lock screen, even if I leave the screen off for hours. It only (very reliably) crashes plasmashell, which then proceeds to cleanly recover. So it looks like DPMS has to get involved in order to reproduce the kscreenlocker crash.
(In reply to Hadrien G. from comment #4) > Most of the coredumps are from plasmashell from resuming from sleep or > power-cycling the monitor, which I suspect to be a different issue. I should > probably create a different bug report for those crashes. But if you prefer, > I can add some of them here. Yes, different coredumps from different crashes should each be in a separate bug report. > However, there are actually a few that I missed from kscreenlocker_greet. > Here is the most recent one: Thanks! That's helpful.
Thank you for the very high quality bug report with a lot of debugging already done!
On current versions of Plasma & the linux kernel, this bug does not happen anymore, which allowed me to turn screen power management back on. But a few other suspicious things still happen around screen lock/unlock cycles : - When unlocking the screen, the first few keystrokes are not recorded, which is pretty annoying and doesn't happen on my other plasma-powered machines. It's as if keyboard input only turned back on after the screen turned back on. To be clear, the computer as a whole is not going out of S3 sleep, it was running all along, it's just the screen that is turning back on from DPMS. - I semi-regularly (once a week ?) see plasmashell crashing and restarting right after unlocking the screen. It's not clear to me why sometimes it happens and sometimes it doesn't. Maybe some kind of race condition ? I guess those belong to different bug reports though ?
(In reply to Hadrien G. from comment #8) > On current versions of Plasma & the linux kernel, this bug does not happen That's great to hear. I'll close this report for now. If you get the same crash, feel free to reopen it. > I guess those belong to different bug reports though ? Yes, please. We need there to be one issue per report so they are actionable.