Bug 488756

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