Created attachment 170625 [details]
Full crash dump info

Created attachment 170626 [details]
Support info - HP

Created attachment 170627 [details]
Support info - Lenovo

I have some additional info.

It reproduced on 6.1.0 (Fedora Kinoite).

Operating System: Fedora Linux 40
KDE Plasma Version: 6.1.0
KDE Frameworks Version: 6.3.0
Qt Version: 6.7.1
Kernel Version: 6.9.4-200.fc40.x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 12 × AMD Ryzen 5 PRO 4650G with Radeon Graphics
Memory: 125.1 GiB of RAM
Graphics Processor: AMD Radeon RX 550 / 550 Series
Manufacturer: HP
Product Name: HP EliteDesk 805 G6 Small Form Factor PC

What is interesting is that the desktop crashed when nobody was at the keyboard and there is nothing in the debug log at all.

This is the output of my `journalctl --user --unit plasma-kwin_wayland.service -b -1 -r`

jun 22 09:35:37 hpelite systemd-coredump[164642]: [🡕] Process 1879 (kwin_wayland) of user 1000 dumped core. (before I woke up today..)
Jun 21 22:46:23 hpelite kscreenlocker_greet[130205]: kf.svg: findInCache with a lastModified timestamp of 0 is deprecated
.... repeats a lot ....
Jun 21 22:46:23 hpelite kscreenlocker_greet[130205]: kf.svg: findInCache with a lastModified timestamp of 0 is deprecated
Jun 21 22:46:23 hpelite kscreenlocker_greet[130205]: virtual QStringList Solid::Backends::UPower::UPowerManager::allDevices()  error:  "org.freedesktop.DBus.Error.NameHasNoOwner"
Jun 21 22:41:05 hpelite kwin_wayland[1879]: kwin_libinput: Libinput: event5  - debounce state: DEBOUNCE_STATE_IS_UP_WAITING → DEBOUNCE_EVENT_TIMEOUT → DEBOUNCE_STATE_IS_UP (this is my lock screen time)

I tried to do a bit of digging via gdb and this looks like a nicer trace:

[Current thread is 1 (Thread 0x7fdbee14bb00 (LWP 1798))]
(gdb) bt
#0  0x00007fdbf4795a11 in std::__atomic_base<QThreadData*>::load (this=0x58, __m=std::memory_order_acquire) at /usr/include/c++/14/bits/atomic_base.h:831
#1  std::atomic<QThreadData*>::load (this=0x58, __m=std::memory_order_acquire) at /usr/include/c++/14/atomic:582
#2  QAtomicOps<QThreadData*>::loadAcquire<QThreadData*> (_q_value=...) at /usr/src/debug/qt6-qtbase-6.7.1-2.fc40.x86_64/src/corelib/thread/qatomic_cxx11.h:214
#3  QBasicAtomicPointer<QThreadData>::loadAcquire (this=0x58) at /usr/src/debug/qt6-qtbase-6.7.1-2.fc40.x86_64/src/corelib/thread/qbasicatomic.h:177
#4  QCoreApplication::notifyInternal2 (receiver=0x563bceb5c840, event=0x7ffd8564c4c0) at /usr/src/debug/qt6-qtbase-6.7.1-2.fc40.x86_64/src/corelib/kernel/qcoreapplication.cpp:1125
#5  0x00007fdbf4795d7d in QCoreApplication::sendEvent (receiver=<optimized out>, event=<optimized out>)
    at /usr/src/debug/qt6-qtbase-6.7.1-2.fc40.x86_64/src/corelib/kernel/qcoreapplication.cpp:1575
#6  0x00007fdbf494e097 in QTimerInfoList::activateTimers (this=this@entry=0x563bcb7ed978) at /usr/src/debug/qt6-qtbase-6.7.1-2.fc40.x86_64/src/corelib/kernel/qtimerinfo_unix.cpp:434
#7  0x00007fdbf49503c0 in QEventDispatcherUNIXPrivate::activateTimers (this=this@entry=0x563bcb7ed8a0)
    at /usr/src/debug/qt6-qtbase-6.7.1-2.fc40.x86_64/src/corelib/kernel/qeventdispatcher_unix.cpp:196
#8  0x00007fdbf49525cb in QEventDispatcherUNIX::processEvents (this=<optimized out>, flags=...) at /usr/src/debug/qt6-qtbase-6.7.1-2.fc40.x86_64/src/corelib/kernel/qeventdispatcher_unix.cpp:472
#9  0x00007fdbf5554e12 in QUnixEventDispatcherQPA::processEvents (this=<optimized out>, flags=...)
    at /usr/src/debug/qt6-qtbase-6.7.1-2.fc40.x86_64/src/gui/platform/unix/qunixeventdispatcher.cpp:27
#10 0x00007fdbf47a2713 in QEventLoop::exec (this=this@entry=0x7ffd8564c690, flags=..., flags@entry=...) at /usr/src/debug/qt6-qtbase-6.7.1-2.fc40.x86_64/src/corelib/global/qflags.h:34
#11 0x00007fdbf479e69c in QCoreApplication::exec () at /usr/src/debug/qt6-qtbase-6.7.1-2.fc40.x86_64/src/corelib/global/qflags.h:74
#12 0x00007fdbf4fd53dd in QGuiApplication::exec () at /usr/src/debug/qt6-qtbase-6.7.1-2.fc40.x86_64/src/gui/kernel/qguiapplication.cpp:1926
#13 0x00007fdbf5b8b0d9 in QApplication::exec () at /usr/src/debug/qt6-qtbase-6.7.1-2.fc40.x86_64/src/widgets/kernel/qapplication.cpp:2555
#14 0x0000563bc436c215 in main (argc=<optimized out>, argv=<optimized out>) at /usr/src/debug/kwin-6.1.0-3.fc40.x86_64/src/main_wayland.cpp:641

And looking at the Qt part of the trace, it looks like the error is here:

#4  QCoreApplication::notifyInternal2 (receiver=0x563bceb5c840, event=0x7ffd8564c4c0) at /usr/src/debug/qt6-qtbase-6.7.1-2.fc40.x86_64/src/corelib/kernel/qcoreapplication.cpp:1125

1120        // Qt enforces the rule that events can only be sent to objects in
1121        // the current thread, so receiver->d_func()->threadData is
1122        // equivalent to QThreadData::current(), just without the function
1123        // call overhead.
1124        QObjectPrivate *d = receiver->d_func();
1125        QThreadData *threadData = d->threadData.loadAcquire();


(gdb) p receiver
$3 = (QObject *) 0x563bceb5c840
(gdb) p d
$4 = (QObjectPrivate *) 0x0

QObjectPrivate is NULL!

It is a (once per day?) timer event

(gdb) p *currentTimerInfo
$17 = {timeout = {__d = {__r = 227723000000000}}, interval = {__r = 86400000}, id = 24, timerType = Qt::VeryCoarseTimer, obj = 0x563bceb5c840, activateRef = 0x7ffd8564c4b8}

Trying to reach

(gdb) p *currentTimerInfo->obj
$23 = {_vptr.QObject = 0x0, static staticMetaObject = {d = {superdata = {direct = 0x0}, stringdata = 0x7fdbf4ad2be0 <(anonymous namespace)::qt_meta_stringdata_CLASSQObjectENDCLASS>, 
      data = 0x7fdbf4ad2ac0 <qt_meta_data_CLASSQObjectENDCLASS>, static_metacall = 0x7fdbf47f7bc0 <QObject::qt_static_metacall(QObject*, QMetaObject::Call, int, void**)>, 
      relatedMetaObjects = 0x0, 
      metaTypes = 0x7fdbf4c81a60 <qt_incomplete_metaTypeArray<(anonymous namespace)::qt_meta_stringdata_CLASSQObjectENDCLASS_t, QtPrivate::TypeAndForceComplete<QString, std::integral_constant<bool, true> >, QtPrivate::TypeAndForceComplete<QObject, std::integral_constant<bool, true> >, QtPrivate::TypeAndForceComplete<void, std::integral_constant<bool, false> >, QtPrivate::TypeAndForceComplete<QObject*, std::integral_constant<bool, false> >, QtPrivate::TypeAndForceComplete<void, std::integral_constant<bool, false> >, QtPrivate::TypeAndForceComplete<void, std::integral_constant<bool, false> >, QtPrivate::TypeAndForceComplete<QString const&, std::integral_constant<bool, false> >, QtPrivate::TypeAndForceComplete<void, std::integral_constant<bool, false> >, QtPrivate::TypeAndForceComplete<QObject*, std::integral_constant<bool, false> > >>, extradata = 0x0}}, d_ptr = {d = 0x0}}

With d_ptr set to NULL.

This is probably as far as I can get without additional guidance.

This is also still happening on Plasma 6.1.1

Operating System: Fedora Linux 40
KDE Plasma Version: 6.1.1
KDE Frameworks Version: 6.3.0
Qt Version: 6.7.1
Kernel Version: 6.9.5-200.fc40.x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 12 × AMD Ryzen 5 PRO 4650G with Radeon Graphics
Memory: 125.1 GiB of RAM
Graphics Processor: AMD Radeon RX 550 / 550 Series
Manufacturer: HP
Product Name: HP EliteDesk 805 G6 Small Form Factor PC

Also happens here. Since it's a timer event not triggered by the user, I can't give much info.

Operating System: Fedora Linux 40
KDE Plasma Version: 6.1.1
KDE Frameworks Version: 6.3.0
Qt Version: 6.7.1
Kernel Version: 6.9.5-200.fc40.x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 12 × Intel® Core™ i7-9750H CPU @ 2.60GHz
Memory: 62.5 GiB of RAM
Graphics Processor: Mesa Intel® UHD Graphics 630
Manufacturer: Intel(R) Client Systems
Product Name: NUC9i7QNX
System Version: K49244-405

I have the same issue. In my case it is triggered when I unplug my USB-C Docking Station.

Operating System: Arch Linux 
KDE Plasma Version: 6.1.1
KDE Frameworks Version: 6.3.0
Qt Version: 6.7.2
Kernel Version: 6.9.7-arch1-1 (64-bit)
Graphics Platform: Wayland
Processors: 8 × Intel® Core™ i7-7700HQ CPU @ 2.80GHz
Memory: 31,2 GiB of RAM
Graphics Processor: Mesa Intel® HD Graphics 630
Manufacturer: Dell Inc.
Product Name: XPS 15 9560

Created attachment 171319 [details]
Stack trace

*** Bug 489410 has been marked as a duplicate of this bug. ***

*** Bug 488756 has been marked as a duplicate of this bug. ***

FWIW: updated to 6.1.3 a few days ago, haven't crashed so far. Might be a problem in Qt that got fixed in-between, anyway, glad to see it solved.

(In reply to Blair Noctis from comment #14)
> FWIW: updated to 6.1.3 a few days ago, haven't crashed so far. Might be a
> problem in Qt that got fixed in-between, anyway, glad to see it solved.

There haven't been any Qt updates though. Anyways, still happening for me on Arch Plasma 6.1.3.

(In reply to Dashon from comment #15)
> (In reply to Blair Noctis from comment #14)
> > FWIW: updated to 6.1.3 a few days ago, haven't crashed so far. Might be a
> > problem in Qt that got fixed in-between, anyway, glad to see it solved.
> 
> There haven't been any Qt updates though. Anyways, still happening for me on
> Arch Plasma 6.1.3.

.. And I cheered too early. 5 hours after this update it crashed again. Ugh. Sorry for the noise.

Same here, except crashes are random and infrequent but annoying. No particular usage seems to be the cause.
Have been submitting crash reports as well.

```
(gdb) bt
#0  0x00007f6e64d96cc1 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () at /lib64/libQt6Core.so.6
#1  0x00007f6e64f52a47 in QTimerInfoList::activateTimers() () at /lib64/libQt6Core.so.6
#2  0x00007f6e64f5701b in QEventDispatcherUNIX::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at /lib64/libQt6Core.so.6
#3  0x00007f6e65b63392 in QUnixEventDispatcherQPA::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at /lib64/libQt6Gui.so.6
#4  0x00007f6e64da3b03 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () at /lib64/libQt6Core.so.6
#5  0x00007f6e64d9f9bc in QCoreApplication::exec() () at /lib64/libQt6Core.so.6
#6  0x000055a3a99cd3a1 in main ()
```

Created attachment 172957 [details]
Core dump printout

How do I attach a core dump? 4MB is too small of a limit for that.

*** Bug 492044 has been marked as a duplicate of this bug. ***

Also encountering this consistently at least once per week. Most often when mousing around, but have also observed kwin_wayland just crashing out of nowhere when AFK on the lockscreen. Happens with both laptop monitor and external screens. Sometimes (but not always) the crash is accompanied by dmesg entries that look as follows:

[82181.619886] i915 0000:00:02.0: [drm] *ERROR* Atomic update failure on pipe A (start=156648 end=156649) time 250 us, min 1192, max 1199, scanline start 1189, end 1208

This seems to happen regardless of the VT-d setting in BIOS. I have attempted to collect a backtrace multiple times, but so far /tmp has always been too small (the crash fills it with over 30 GiB of data!) or the corefile instantly becomes "inaccessible" according to coredumpctl.

If it helps with the diagnosis, the system is hibernated between sessions, leading (ideally) to long uptimes...

Operating System: Fedora Linux 40 (Kinoite)
KDE Plasma Version: 6.1.4
KDE Frameworks Version: 6.5.0
Qt Version: 6.7.2
Kernel Version: 6.10.9-cb1.0.fc40.x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 8 × Intel® Core™ i5-8365U CPU @ 1.60GHz
Memory: 31,1 GiB of RAM
Graphics Processor: Mesa Intel® UHD Graphics 620
Manufacturer: LENOVO
System Version: ThinkPad T490

I've been beta testing plasma 6.2 and the issue is till present, so bumping the affected version number.

*** Bug 484042 has been marked as a duplicate of this bug. ***

*** Bug 492346 has been marked as a duplicate of this bug. ***

*** Bug 491797 has been marked as a duplicate of this bug. ***

(In reply to Dashon from comment #23)
> I've been beta testing plasma 6.2 and the issue is till present, so bumping
> the affected version number.

What do you do to reproduce the crash? Anything special about your setup?

(In reply to Vlad Zahorodnii from comment #27)
> (In reply to Dashon from comment #23)
> > I've been beta testing plasma 6.2 and the issue is till present, so bumping
> > the affected version number.
> 
> What do you do to reproduce the crash? Anything special about your setup?

I don't do anything to reproduce the crash. It happens every 24 hours without fail give or take about 15 minutes. As far as I know there is nothing special about my setup. Although it isn't neccessarily the most vanilla. 

System Info:
Operating System: EndeavourOS 
KDE Plasma Version: 6.1.90
KDE Frameworks Version: 6.6.0
Qt Version: 6.8.0
Kernel Version: 6.10.10-zen1-1-zen (64-bit)
Graphics Platform: Wayland
Processors: 16 × AMD Ryzen 7 5800X 8-Core Processor
Memory: 62.7 GiB of RAM
Graphics Processor: NVIDIA GeForce RTX 3080/PCIe/SSE2
Manufacturer: Micro-Star International Co., Ltd.
Product Name: MS-7C95
System Version: 1.0

This is a dual monitor setup. I bought the exact two of the exact same model monitors to hopefully avoid issues.
Monitor Brand and Model
MSI MAG274QRF-QD

The only other exotic thing I can think of is that I have a handful of extra hard drives in a zfs raid for storage.

Created attachment 173961 [details]
backtrace

The Plasma Shell crashes almost every day now.
I can't link it to anything and I can't reproduce it. I've replaced the entire computer, only the SSD (ext4) and the two monitors remain, so I don't think it's a hardware issue.

Operating System: Manjaro Linux 
KDE Plasma Version: 6.0.5
KDE Frameworks Version: 6.5.0
Qt Version: 6.7.2
Kernel Version: 6.9.12-3-MANJARO (64-bit)
Graphics Platform: Wayland
Processors: 8 × Intel® Core™ i7-4770K CPU @ 3.50GHz
Memory: 23,3 GiB of RAM
Graphics Processor: Mesa Intel® HD Graphics 4600
Manufacturer: ASUS
Product Name: All Series

> What do you do to reproduce the crash? Anything special about your setup?

No, same as Dashon. I do nothing special, my reproducer is:

1) Boot to KDE
2) Start Firefox
3) wait 24 hours -+ few minutes
4) observe the crash

It does not matter whether I work with the machine at the time of the crash or whether I am gone for he weekend.

And it happens on three different machines that I have. There is no common denominator except the username, Fedora 40 and KDE.

The machines are:
- both Intel and AMD,
- with and without extra GPU (AMD, Intel),
- both laptop and desktop (without battery),
- with either SSD or NVMe,
- one on wired and two on wifi network
- with and without extra monitors (and both HDMI and DisplayPort)

(In reply to Martin from comment #30)
> 3) wait 24 hours -+ few minutes
> 4) observe the crash

If you change the time in system settings, does the crash occur?

(In reply to Vlad Zahorodnii from comment #31)
> (In reply to Martin from comment #30)
> > 3) wait 24 hours -+ few minutes
> > 4) observe the crash
> 
> If you change the time in system settings, does the crash occur?

I'll be sure to let you know. Currently it is set to set time and date automatically, but I will test with setting it manually an hour before the 24 hour mark where the crash is going to occur.

(In reply to Vlad Zahorodnii from comment #31)
> (In reply to Martin from comment #30)
> > 3) wait 24 hours -+ few minutes
> > 4) observe the crash
> 
> If you change the time in system settings, does the crash occur?

So far, I believe this suggestion has worked and allowed me to avoid today's crash.  It is officially one hour past the 24 hour mark without a crash occurring. I manually set the time to be about 10 hours ahead and it hasn't crashed yet. I will let you know if kwin crashes sometime in the next couple hours to see if it is just delayed.

Does this mean there is something going wrong with setting the date and time automatically?

(In reply to Dashon from comment #32)
> (In reply to Vlad Zahorodnii from comment #31)
> > (In reply to Martin from comment #30)
> > > 3) wait 24 hours -+ few minutes
> > > 4) observe the crash
> > 
> > If you change the time in system settings, does the crash occur?
> 
> I'll be sure to let you know. Currently it is set to set time and date
> automatically, but I will test with setting it manually an hour before the
> 24 hour mark where the crash is going to occur.

Ended up needing to reboot. Will see if a crash occurs tomorrow with set automatic time disabled.

(In reply to Dashon from comment #33)
> (In reply to Vlad Zahorodnii from comment #31)
> > (In reply to Martin from comment #30)
> > > 3) wait 24 hours -+ few minutes
> > > 4) observe the crash
> > 
> > If you change the time in system settings, does the crash occur?
> 
> So far, I believe this suggestion has worked and allowed me to avoid today's
> crash.  It is officially one hour past the 24 hour mark without a crash
> occurring. I manually set the time to be about 10 hours ahead and it hasn't
> crashed yet. I will let you know if kwin crashes sometime in the next couple
> hours to see if it is just delayed.
> 
> Does this mean there is something going wrong with setting the date and time
> automatically?

No idea. To be honest, I asked about changing the system time hoping to find a reliable-ish way to reproduce the crash.

Still reproducible after an upgrade with

Operating System: Fedora Linux 40 (Kinoite)
KDE Plasma Version: 6.1.5
KDE Frameworks Version: 6.6.0

I'm starting to believe the 24h timer theory, the system seemed to be running for about that length of time (including hibernation in between) before kwin_wayland was once again taken down with all (non-Qt) applications. Still can't extract a backtrace on Kinoite.

(In reply to Dennis Marttinen from comment #36)
> Still reproducible after an upgrade with
> 
> Operating System: Fedora Linux 40 (Kinoite)
> KDE Plasma Version: 6.1.5
> KDE Frameworks Version: 6.6.0
> 
> I'm starting to believe the 24h timer theory, the system seemed to be
> running for about that length of time (including hibernation in between)
> before kwin_wayland was once again taken down with all (non-Qt)
> applications. Still can't extract a backtrace on Kinoite.

Okay... can you try disabling NTP/automatic time?

NTP seems to be handled by chronyd, I've now executed `sudo timedatectl set-ntp false` and confirmed it's no longer running. Let's see if the crash still occurs tonight.

I stopped the ntp synchronization, turned off the Global Menu and removed the Individual Core Usage widget. Now I don't know about any extra settings.
I look forward to the result.

(In reply to Vlad Zahorodnii from comment #35)
> (In reply to Dashon from comment #33)
> > (In reply to Vlad Zahorodnii from comment #31)
> > > (In reply to Martin from comment #30)
> > > > 3) wait 24 hours -+ few minutes
> > > > 4) observe the crash
> > > 
> > > If you change the time in system settings, does the crash occur?
> > 
> > So far, I believe this suggestion has worked and allowed me to avoid today's
> > crash.  It is officially one hour past the 24 hour mark without a crash
> > occurring. I manually set the time to be about 10 hours ahead and it hasn't
> > crashed yet. I will let you know if kwin crashes sometime in the next couple
> > hours to see if it is just delayed.
> > 
> > Does this mean there is something going wrong with setting the date and time
> > automatically?
> 
> No idea. To be honest, I asked about changing the system time hoping to find
> a reliable-ish way to reproduce the crash.

Unfortunately, disabling the set automatic time and date in system settings did not prevent the crash. I will try changing the time just before the crash is supposed to happen again tomorrow to see if that reliably works.

Disabling Automatic date and time using the Settings KDE app seems to have done something. Because at least the crash I expected last night have not happened yet. It has been more than 24 h since the last time. But I will wait till tonight (24 h from changing the setting) to be sure.

(In reply to Vlad Zahorodnii from comment #35)
> (In reply to Dashon from comment #33)
> > (In reply to Vlad Zahorodnii from comment #31)
> > > (In reply to Martin from comment #30)
> > > > 3) wait 24 hours -+ few minutes
> > > > 4) observe the crash
> > > 
> > > If you change the time in system settings, does the crash occur?
> > 
> > So far, I believe this suggestion has worked and allowed me to avoid today's
> > crash.  It is officially one hour past the 24 hour mark without a crash
> > occurring. I manually set the time to be about 10 hours ahead and it hasn't
> > crashed yet. I will let you know if kwin crashes sometime in the next couple
> > hours to see if it is just delayed.
> > 
> > Does this mean there is something going wrong with setting the date and time
> > automatically?
> 
> No idea. To be honest, I asked about changing the system time hoping to find
> a reliable-ish way to reproduce the crash.

Changing the time didn't stop today's crash either. This time I set it to be an hour earlier than it actually was rather than 10 hours ahead. Perhaps the first time was just a fluke or maybe I altered the date too on the first day. I'll have to test that theory tomorrow.

Ok, I confirm that disabling automatic time updates does not fix the issue. It did reproduce again for me as well.

(In reply to Vlad Zahorodnii from comment #35)
> (In reply to Dashon from comment #33)
> > (In reply to Vlad Zahorodnii from comment #31)
> > > (In reply to Martin from comment #30)
> > > > 3) wait 24 hours -+ few minutes
> > > > 4) observe the crash
> > > 
> > > If you change the time in system settings, does the crash occur?
> > 
> > So far, I believe this suggestion has worked and allowed me to avoid today's
> > crash.  It is officially one hour past the 24 hour mark without a crash
> > occurring. I manually set the time to be about 10 hours ahead and it hasn't
> > crashed yet. I will let you know if kwin crashes sometime in the next couple
> > hours to see if it is just delayed.
> > 
> > Does this mean there is something going wrong with setting the date and time
> > automatically?
> 
> No idea. To be honest, I asked about changing the system time hoping to find
> a reliable-ish way to reproduce the crash.

Setting the time forward didn't stop the crash either. All that is left is changing the date.

Reproduced as well with automatic time sync off, another kwin_wayland crash after

18:13:22 up 3 days, 20:46,  1 user,  load average: 1,16, 4,38, 4,92

This is all I managed to capture from the crash this time around:

Core was generated by `/usr/bin/kwin_wayland --wayland-fd 7 --socket wayland-0 --xwayland-fd 8 --xwayl'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x000075c5f8396d81 in ?? ()
[Current thread is 1 (LWP 1685)]
Cannot QML trace cores :(
[Current thread is 1 (LWP 1685)]

Thread 36 (LWP 38306):
Backtrace stopped: Cannot access memory at address 0x75b980bff9e0

Thread 35 (LWP 38304):
Backtrace stopped: Cannot access memory at address 0x75b981fff890

Thread 34 (LWP 1765):
Backtrace stopped: Cannot access memory at address 0x75c5c7dff8c0

Thread 33 (LWP 1747):
Backtrace stopped: Cannot access memory at address 0x75c5d4bff8c0

... (lots more lines like the above)

dmesg shows the following:

[87583.322771] kwin_wayland[1685]: segfault at 5f ip 000075c5f8396d81 sp 00007ffc94e888c0 error 4 in libQt6Core.so.6.7.2[196d81,75c5f82b1000+406000] likely on CPU 6 (core 2, socket 0)
[87583.322782] Code: 31 ff 48 8d 75 b0 c6 45 af 00 48 89 5d b0 4c 89 65 b8 48 89 45 c0 e8 ce 17 f3 ff 84 c0 75 6d 48 8b 43 08 48 8d 0d 3f ff ff ff <4c> 8b 78 58 4d 89 fe 41 8b 57 08 49 8b 7d 00 8d 42 01 41 89 47 08

(In reply to Vlad Zahorodnii from comment #35)
> (In reply to Dashon from comment #33)
> > (In reply to Vlad Zahorodnii from comment #31)
> > > (In reply to Martin from comment #30)
> > > > 3) wait 24 hours -+ few minutes
> > > > 4) observe the crash
> > > 
> > > If you change the time in system settings, does the crash occur?
> > 
> > So far, I believe this suggestion has worked and allowed me to avoid today's
> > crash.  It is officially one hour past the 24 hour mark without a crash
> > occurring. I manually set the time to be about 10 hours ahead and it hasn't
> > crashed yet. I will let you know if kwin crashes sometime in the next couple
> > hours to see if it is just delayed.
> > 
> > Does this mean there is something going wrong with setting the date and time
> > automatically?
> 
> No idea. To be honest, I asked about changing the system time hoping to find
> a reliable-ish way to reproduce the crash.

Today tried changing just the date and unfortunately that did not stop the crash either. So I'm all out of options regarding that route. All we know so far is that it happens at least for me every 24 hours give or take some amount of minutes and that the crash report references some type of Qtimer. Unfortunately, although Arch now supports debuginfod. I still regularly end up with missing debug symbols in any kind of backtrace that I try to create. Whether it be manually or through dr konqi.

(In reply to Martin from comment #7)
> It is a (once per day?) timer event
> 
> (gdb) p *currentTimerInfo
> $17 = {timeout = {__d = {__r = 227723000000000}}, interval = {__r =
> 86400000}, id = 24, timerType = Qt::VeryCoarseTimer, obj = 0x563bceb5c840,
> activateRef = 0x7ffd8564c4b8}

Indeed, it is. The next question: do all crashes have the same interval?

(and, most importantly, who does register a timer with such an interval)

Does any of you use overview? and do you type in overview to search? it seems like it may create a long running timer. What if you avoid using overview for a day?

this timer https://invent.kde.org/plasma/kdeplasma-addons/-/blob/a11e3d254a2931130664f5cd23e79f4104eac217/runners/converter/converterrunner.cpp#L53

it's in the unit converter runner

(In reply to Vlad Zahorodnii from comment #48)
> Does any of you use overview? and do you type in overview to search? it
> seems like it may create a long running timer. What if you avoid using
> overview for a day?

I use the overview everyday. I'll try avoiding it and then report back.

(In reply to Vlad Zahorodnii from comment #48)
> Does any of you use overview? and do you type in overview to search? it
> seems like it may create a long running timer. What if you avoid using
> overview for a day?

or disable "Unit Converter" search plugin in krunner?

(In reply to Vlad Zahorodnii from comment #51)
> (In reply to Vlad Zahorodnii from comment #48)
> > Does any of you use overview? and do you type in overview to search? it
> > seems like it may create a long running timer. What if you avoid using
> > overview for a day?
> 
> or disable "Unit Converter" search plugin in krunner?

I'll do both just to be sure. Disable the unit converter and not use the overview.

A possibly relevant merge request was started @ https://invent.kde.org/plasma/kdeplasma-addons/-/merge_requests/630

Git commit 1245968618afff3a0bba5e2c6088e77f0c9f8aff by Vlad Zahorodnii.
Committed on 28/09/2024 at 16:24.
Pushed by vladz into branch 'master'.

runners/converter: Fix thread affinity of currency update timer

Amends 8f164924d06015db13a8b703fdfa1258d7f8d718.

The runner lives in a separate thread, but the currency update timer
lives on the main thread. Furthermore, the update timer is owned by
the runner, which is not okay because its thread affinity is different.
It also means that the event loop on the main thread may not properly
clean up its timer list.

In order to fix the issue, this change makes the update timer a child
of the runner object. With that, both will have the same thread affinity.

M  +4    -3    runners/converter/converterrunner.cpp
M  +1    -1    runners/converter/converterrunner.h

https://invent.kde.org/plasma/kdeplasma-addons/-/commit/1245968618afff3a0bba5e2c6088e77f0c9f8aff

Git commit 06d0cd9cd918e52155804b25623c5b9cf4d5c6cb by Vlad Zahorodnii.
Committed on 28/09/2024 at 16:34.
Pushed by vladz into branch 'Plasma/6.2'.

runners/converter: Fix thread affinity of currency update timer

Amends 8f164924d06015db13a8b703fdfa1258d7f8d718.

The runner lives in a separate thread, but the currency update timer
lives on the main thread. Furthermore, the update timer is owned by
the runner, which is not okay because its thread affinity is different.
It also means that the event loop on the main thread may not properly
clean up its timer list.

In order to fix the issue, this change makes the update timer a child
of the runner object. With that, both will have the same thread affinity.


(cherry picked from commit 1245968618afff3a0bba5e2c6088e77f0c9f8aff)

Co-authored-by: Vlad Zahorodnii <vlad.zahorodnii@kde.org>

M  +4    -3    runners/converter/converterrunner.cpp
M  +1    -1    runners/converter/converterrunner.h

https://invent.kde.org/plasma/kdeplasma-addons/-/commit/06d0cd9cd918e52155804b25623c5b9cf4d5c6cb

(In reply to Dashon from comment #52)
> (In reply to Vlad Zahorodnii from comment #51)
> > (In reply to Vlad Zahorodnii from comment #48)
> > > Does any of you use overview? and do you type in overview to search? it
> > > seems like it may create a long running timer. What if you avoid using
> > > overview for a day?
> > 
> > or disable "Unit Converter" search plugin in krunner?
> 
> I'll do both just to be sure. Disable the unit converter and not use the
> overview.

Thank you!

I just turned off the unit converter

Created attachment 174206 [details]
kwin wayland crash

Unit Converter turned off, the crash happened again.  For me, the error usually appears on the second day, but the machine sleeps a lot.

(In reply to Zoltán KADA from comment #58)
> Created attachment 174206 [details]
> kwin wayland crash
> 
> Unit Converter turned off, the crash happened again.  For me, the error
> usually appears on the second day, but the machine sleeps a lot.

Hmm what if you avoid using overview?

also note that you would need to reboot after turning off the unit converter runner

(In reply to Vlad Zahorodnii from comment #60)
> also note that you would need to reboot after turning off the unit converter
> runner

So far the crash hasn't happened for me and I disabled the unit converter, avoided the overview and rebooted yesterday after applying those changes. I will keep monitoring to situation to ensure this holds true.

(In reply to Vlad Zahorodnii from comment #60)
> also note that you would need to reboot after turning off the unit converter
> runner

After turning off Unit Converter, I did not restart it.
However, after the crash today, I restarted it. I'll let you know if it crashes again.

(In reply to Vlad Zahorodnii from comment #60)
> also note that you would need to reboot after turning off the unit converter
> runner

Officially two days without a crash. I believe the issue is solved. Thanks, so much.

Okay, thanks. Then the crash should be fixed in 6.2.0

*** Bug 473260 has been marked as a duplicate of this bug. ***

Can confirm as well that disabling the unit converter did the trick, even when heavily using the overview. Up for over 4 days now with multiple hibernation cycles, no more crashing. Thanks!

No crashes in the 4 days since turning off Unit Converter and restarting the machine.
I can confirm that Unit Converter caused the problem.

Same here, disabling the Unit converter plugin stopped the crashes. Thanks.

Can confirm that with unit converter enabled it no longer crashes. Thanks for the fix!