SUMMARY I'm seeing a recurrent but somewhat rare crash in kwin_wayland that maybe happens once a week or so on a computer I use heavily, and I'm not sure what triggers it. It seems to be unrelated to https://bugs.kde.org/show_bug.cgi?id=488668 which happens 1+ times a day on the same machine. I managed to extract a backtrace of this new, more rare crash and I believe I saw it with Plasma 5 too although I'm not sure (I didn't know how to use coredumpctl at that time): #0 QScopedScopeLevelCounter::QScopedScopeLevelCounter(QThreadData*) (threadData=0x0, this=<synthetic pointer>) at /usr/src/debug/qtbase-everywhere-src-6.7.1/src/corelib/thread/qthread_p.h:339 #1 QCoreApplication::notifyInternal2(QObject*, QEvent*) (receiver=0x55f8bf6fc350, event=0x7ffdcc2dbb10) at /usr/src/debug/qtbase-everywhere-src-6.7.1/src/corelib/kernel/qcoreapplication.cpp:1126 #2 0x00007f4108ceca5a in QTimerInfoList::activateTimers() (this=0x55f8bb79a8e8) at /usr/src/debug/qtbase-everywhere-src-6.7.1/src/corelib/kernel/qtimerinfo_unix.cpp:434 #3 0x00007f4108cf35ec in QEventDispatcherUNIX::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) (this=<optimized out>, flags=..., flags@entry=...) at /usr/src/debug/qtbase-everywhere-src-6.7.1/src/corelib/kernel/qeventdispatcher_unix.cpp:472 #4 0x00007f410980b47d in QUnixEventDispatcherQPA::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) (this=<optimized out>, flags=...) at /usr/src/debug/qtbase-everywhere-src-6.7.1/src/gui/platform/unix/qunixeventdispatcher.cpp:27 #5 0x00007f4108b9959b in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) (this=0x7ffdcc2dbcf0, flags=...) at /usr/src/debug/qtbase-everywhere-src-6.7.1/src/corelib/global/qflags.h:34 #6 0x00007f4108b92da6 in QCoreApplication::exec() () at /usr/src/debug/qtbase-everywhere-src-6.7.1/src/corelib/global/qflags.h:74 #7 0x00007f41093e7e8c in QGuiApplication::exec() () at /usr/src/debug/qtbase-everywhere-src-6.7.1/src/gui/kernel/qguiapplication.cpp:1926 #8 0x00007f4109dc0005 in QApplication::exec() () at /usr/src/debug/qtbase-everywhere-src-6.7.1/src/widgets/kernel/qapplication.cpp:2555 #9 0x000055f89dcbf702 in main(int, char**) (argc=<optimized out>, argv=<optimized out>) at /usr/src/debug/kwin-6.0.5/src/main_wayland.cpp:609 SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: openSUSE Slowroll (available in About System) KDE Plasma Version: plasmashell 6.0.5 KDE Frameworks Version: 6.2.0 Qt Version: 6.7.1 ADDITIONAL INFORMATION
That trace does not indicate anything helpful, I don't think that indicates where a crash occured. It's just at the event loop. When you run coredumpctl gdb kwin_wayland can you also include the line: Program terminated with signal XYZ, Aborted.
Let me know if any of this is helpful: # coredumpctl gdb kwin_wayland PID: 3302 (kwin_wayland) UID: 1000 (user) GID: 100 (users) Signal: 11 (SEGV) Timestamp: Wed 2024-06-19 21:47:34 CEST (20h ago) Command Line: /usr/bin/kwin_wayland --wayland-fd 7 --socket wayland-0 --xwayland-fd 8 --xwayland-fd 9 --xwayland-display :1 --xwayland-xauthority /run/user/1000/xauth_HvlSgm --xwayland Executable: /usr/bin/kwin_wayland Control Group: /user.slice/user-1000.slice/user@1000.service/session.slice/plasma-kwin_wayland.service Unit: user@1000.service User Unit: plasma-kwin_wayland.service Slice: user-1000.slice Owner UID: 1000 (user) Boot ID: REDACTED Machine ID: REDACTED Hostname: REDACTED Storage: /var/lib/systemd/coredump/core.kwin_wayland.1000.593309d9ee43430288457d2f7e3ce20b.3302.1718826454000000.zst (present) Size on Disk: 29.7M Message: Process 3302 (kwin_wayland) of user 1000 dumped core. Stack trace of thread 3302: #0 0x00007f4108b8ed4b _ZN24QScopedScopeLevelCounterC4EP11QThreadData (libQt6Core.so.6 + 0x18ed4b) #1 0x00007f4108ceca5a _ZN14QTimerInfoList14activateTimersEv (libQt6Core.so.6 + 0x2eca5a) #2 0x00007f4108cf35ec _ZN20QEventDispatcherUNIX13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE (libQt6Core.so.6 + 0x2f35ec) #3 0x00007f410980b47d _ZN23QUnixEventDispatcherQPA13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE (libQt6Gui.so.6 + 0x60b47d) #4 0x00007f4108b9959b _ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE (libQt6Core.so.6 + 0x19959b) #5 0x00007f4108b92da6 _ZN16QCoreApplication4execEv (libQt6Core.so.6 + 0x192da6) #6 0x000055f89dcbf702 main (kwin_wayland + 0x55702) #7 0x00007f410822a1f0 __libc_start_call_main (libc.so.6 + 0x2a1f0) #8 0x00007f410822a2b9 __libc_start_main_impl (libc.so.6 + 0x2a2b9) #9 0x000055f89dcc4e35 _start (kwin_wayland + 0x5ae35) Stack trace of thread 3331: #0 0x00007f410828efee __futex_abstimed_wait_common64 (libc.so.6 + 0x8efee) #1 0x00007f4108291d30 __pthread_cond_wait_common (libc.so.6 + 0x91d30) #2 0x00007f40fdd10edb n/a (/usr/lib64/dri/radeonsi_dri.so (deleted) + 0x110edb) ELF object binary architecture: AMD x86-64 And in gdb: 0 QScopedScopeLevelCounter::QScopedScopeLevelCounter (threadData=0x0, this=<synthetic pointer>) at /usr/src/debug/qtbase-everywhere-src-6.7.1/src/corelib/thread/qthread_p.h:339 339 { ++threadData->scopeLevel; } [Current thread is 1 (Thread 0x7f4105339200 (LWP 3302))] (gdb) print threadData $1 = (QThreadData *) 0x0 It seems to have been a null pointer crash.
https://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/kernel/qcoreapplication.cpp?h=6.7.1#n1125 This line seems to have returned a null pointer for `.loadAcquire()` in line 1125, and then the crash backtrace descends into ilne 1126 with threadData set to that null pointer. Seems almost like a bug in Qt that this isn't checked...?
I just got another crash, it's a different backtrace but since it also goes into events and QThread, it feels like this is a related problem and there's just something set up wrong with the Qt threading: Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00007f5fd718ed44 in std::__atomic_base<QThreadData*>::load(std::memory_order) const (__m=std::memory_order_acquire, this=0x73) at /usr/include/c++/13/bits/atomic_base.h:835 #1 std::atomic<QThreadData*>::load(std::memory_order) const (__m=std::memory_order_acquire, this=0x73) at /usr/include/c++/13/atomic:577 #2 QAtomicOps<QThreadData*>::loadAcquire<QThreadData*>(std::atomic<QThreadData*> const&) (_q_value=<error reading variable: Cannot access memory at address 0x73>) at /usr/src/debug/qtbase-everywhere-src-6.7.1/src/corelib/thread/qatomic_cxx11.h:214 #3 QBasicAtomicPointer<QThreadData>::loadAcquire() const (this=0x73) at /usr/src/debug/qtbase-everywhere-src-6.7.1/src/corelib/thread/qbasicatomic.h:177 #4 QCoreApplication::notifyInternal2(QObject*, QEvent*) (receiver=0x5593d328a1d0, event=0x7ffc29cece30) at /usr/src/debug/qtbase-everywhere-src-6.7.1/src/corelib/kernel/qcoreapplication.cpp:1125 #5 0x00007f5fd72eca5a in QTimerInfoList::activateTimers() (this=0x5593cd605a48) at /usr/src/debug/qtbase-everywhere-src-6.7.1/src/corelib/kernel/qtimerinfo_unix.cpp:434 #6 0x00007f5fd72f35ec in QEventDispatcherUNIX::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) (this=<optimized out>, flags=..., flags@entry=...) at /usr/src/debug/qtbase-everywhere-src-6.7.1/src/corelib/kernel/qeventdispatcher_unix.cpp:472 #7 0x00007f5fd7e0b47d in QUnixEventDispatcherQPA::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) (this=<optimized out>, flags=...) at /usr/src/debug/qtbase-everywhere-src-6.7.1/src/gui/platform/unix/qunixeventdispatcher.cpp:27 #8 0x00007f5fd719959b in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) (this=0x7ffc29ced010, flags=...) at /usr/src/debug/qtbase-everywhere-src-6.7.1/src/corelib/global/qflags.h:34 #9 0x00007f5fd7192da6 in QCoreApplication::exec() () at /usr/src/debug/qtbase-everywhere-src-6.7.1/src/corelib/global/qflags.h:74 #10 0x00007f5fd79e7e8c in QGuiApplication::exec() () at /usr/src/debug/qtbase-everywhere-src-6.7.1/src/gui/kernel/qguiapplication.cpp:1926 #11 0x00007f5fd85c0005 in QApplication::exec() () at /usr/src/debug/qtbase-everywhere-src-6.7.1/src/widgets/kernel/qapplication.cpp:2555 #12 0x00005593b621b702 in main(int, char**) (argc=<optimized out>, argv=<optimized out>) at /usr/src/debug/kwin-6.0.5/src/main_wayland.cpp:609
I answered above question that it didn't look like a SIGSEGV, by pasting the info that it was a SIGSEGV with more info about the exact line and what exactly was a null pointer there. Should I reopen, since that hopefully provides the needed info? I'm doing that now, sorry if that's not what I was suppose to be doing.
*** Bug 486732 has been marked as a duplicate of this bug. ***
*** Bug 488994 has been marked as a duplicate of this bug. ***
*** This bug has been marked as a duplicate of bug 488713 ***