Bug 501285

...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.