Created attachment 182923 [details]
New crash information added by DrKonqi

DrKonqi auto-attaching complete backtrace.

Searchable backtrace

Thread 1 (Thread 0x7f4dd23ab300 (LWP 2305)):
[KCrash Handler]
#5  QConcatenateTablesProxyModel::index (this=0x55b5f32feaf0, row=5, column=0, parent=<optimized out>) at /usr/src/debug/qt6-qtbase-6.9.1-1.fc42.x86_64/src/corelib/itemmodels/qconcatenatetablesproxymodel.cpp:294
#6  0x00007f4dd85d6bba in QSortFilterProxyModelPrivate::proxy_to_source (this=<optimized out>, proxy_index=<optimized out>) at /usr/src/debug/qt6-qtbase-6.9.1-1.fc42.x86_64/src/corelib/itemmodels/qsortfilterproxymodel.cpp:562
#7  QSortFilterProxyModelPrivate::proxy_to_source (this=<optimized out>, proxy_index=<optimized out>) at /usr/src/debug/qt6-qtbase-6.9.1-1.fc42.x86_64/src/corelib/itemmodels/qsortfilterproxymodel.cpp:547
#8  0x00007f4dd85d6f22 in QSortFilterProxyModel::mapToSource (this=<optimized out>, proxyIndex=...) at /usr/src/debug/qt6-qtbase-6.9.1-1.fc42.x86_64/src/corelib/itemmodels/qsortfilterproxymodel.cpp:3281
#9  QSortFilterProxyModel::data (this=<optimized out>, index=..., role=257) at /usr/src/debug/qt6-qtbase-6.9.1-1.fc42.x86_64/src/corelib/itemmodels/qsortfilterproxymodel.cpp:2219
#10 0x00007f4d812c8f08 in QModelIndex::data (this=this@entry=0x7fffc64adb40, arole=arole@entry=257) at /usr/include/qt6/QtCore/qabstractitemmodel.h:518
#11 0x00007f4d812cea47 in TaskManager::TaskGroupingProxyModel::data (this=<optimized out>, proxyIndex=<optimized out>, role=<optimized out>) at /usr/src/debug/plasma-workspace-6.4.1-2.fc42.x86_64/libtaskmanager/taskgroupingproxymodel.cpp:748
#12 0x00007f4dd85d6fca in QSortFilterProxyModel::data (this=this@entry=0x55b5f3b012c0, index=..., role=role@entry=257) at /usr/src/debug/qt6-qtbase-6.9.1-1.fc42.x86_64/src/corelib/itemmodels/qsortfilterproxymodel.cpp:2222
#13 0x00007f4d812d6367 in TaskManager::TasksModel::data (this=0x55b5f3b012c0, proxyIndex=<optimized out>, role=257) at /usr/src/debug/plasma-workspace-6.4.1-2.fc42.x86_64/libtaskmanager/tasksmodel.cpp:1078
#14 0x00007f4dd858bad6 in QAbstractItemModel::qt_static_metacall (_o=_o@entry=0x55b5f3b012c0, _c=_c@entry=QMetaObject::InvokeMetaMethod, _id=_id@entry=38, _a=_a@entry=0x7fffc64ae268) at /usr/src/debug/qt6-qtbase-6.9.1-1.fc42.x86_64/redhat-linux-build/src/corelib/Core_autogen/include/moc_qabstractitemmodel.cpp:504
#15 0x00007f4dd85967ba in QAbstractItemModel::qt_metacall (this=this@entry=0x55b5f3b012c0, _c=_c@entry=QMetaObject::InvokeMetaMethod, _id=38, _a=_a@entry=0x7fffc64ae268) at /usr/src/debug/qt6-qtbase-6.9.1-1.fc42.x86_64/redhat-linux-build/src/corelib/Core_autogen/include/moc_qabstractitemmodel.cpp:644
#16 0x00007f4dd85bcd2e in QAbstractProxyModel::qt_metacall (this=this@entry=0x55b5f3b012c0, _c=_c@entry=QMetaObject::InvokeMetaMethod, _id=<optimized out>, _a=_a@entry=0x7fffc64ae268) at /usr/src/debug/qt6-qtbase-6.9.1-1.fc42.x86_64/redhat-linux-build/src/corelib/Core_autogen/include/moc_qabstractproxymodel.cpp:202
#17 0x00007f4dd85ea93e in QSortFilterProxyModel::qt_metacall (this=this@entry=0x55b5f3b012c0, _c=_c@entry=QMetaObject::InvokeMetaMethod, _id=<optimized out>, _a=_a@entry=0x7fffc64ae268) at /usr/src/debug/qt6-qtbase-6.9.1-1.fc42.x86_64/redhat-linux-build/src/corelib/Core_autogen/include/moc_qsortfilterproxymodel.cpp:264
#18 0x00007f4d812e79fe in TaskManager::TasksModel::qt_metacall (this=0x55b5f3b012c0, _c=QMetaObject::InvokeMetaMethod, _id=<optimized out>, _a=0x7fffc64ae268) at /usr/src/debug/plasma-workspace-6.4.1-2.fc42.x86_64/redhat-linux-build/libtaskmanager/taskmanager_autogen/include/moc_tasksmodel.cpp:682
#19 0x00007f4dd9935782 in QQmlObjectOrGadget::metacall (this=this@entry=0x7fffc64ae550, type=type@entry=QMetaObject::InvokeMetaMethod, index=<optimized out>, index@entry=42, argv=<optimized out>) at /usr/src/debug/qt6-qtdeclarative-6.9.1-2.fc42.x86_64/src/qml/qml/qqmlobjectorgadget.cpp:14
#20 0x00007f4dd97be0b3 in QV4::CallMethod (object=..., index=<optimized out>, returnType=..., argCount=<optimized out>, argTypes=<optimized out>, engine=<optimized out>, callArgs=<optimized out>, callType=<optimized out>) at /usr/include/qt6/QtCore/qvarlengtharray.h:89
#21 QV4::QObjectMethod::callPrecise (object=..., data=<optimized out>, engine=<optimized out>, engine@entry=0x55b5f1131240, callArgs=<optimized out>, callArgs@entry=0x7f4da2ed35d8, callType=callType@entry=QMetaObject::InvokeMetaMethod) at /usr/src/debug/qt6-qtdeclarative-6.9.1-2.fc42.x86_64/src/qml/jsruntime/qv4qobjectwrapper.cpp:2076
#22 0x00007f4dd97c0991 in operator() (__closure=<optimized out>) at /usr/src/debug/qt6-qtdeclarative-6.9.1-2.fc42.x86_64/src/qml/jsruntime/qv4qobjectwrapper.cpp:3078
#23 operator()<QV4::QObjectMethod::callInternal(const QV4::Value*, const QV4::Value*, int) const::<lambda()> > (__closure=<synthetic pointer>, call=<optimized out>) at /usr/src/debug/qt6-qtdeclarative-6.9.1-2.fc42.x86_64/src/qml/jsruntime/qv4qobjectwrapper.cpp:3055
#24 QV4::QObjectMethod::callInternal (this=<optimized out>, thisObject=0x7f4da2ed3578, argv=0x7f4da2ed3590, argc=2) at /usr/src/debug/qt6-qtdeclarative-6.9.1-2.fc42.x86_64/src/qml/jsruntime/qv4qobjectwrapper.cpp:3078
#25 0x00007f4dd97e94a5 in QV4::FunctionObject::call (this=0x7fffc64ae618, thisObject=0x7f4da2ed3578, argv=0x7f4da2ed3590, argc=2) at /usr/src/debug/qt6-qtdeclarative-6.9.1-2.fc42.x86_64/src/qml/jsruntime/qv4functionobject_p.h:187
#26 QV4::Runtime::CallPropertyLookup::call (engine=0x55b5f1131240, base=..., index=<optimized out>, argv=0x7f4da2ed3590, argc=2) at /usr/src/debug/qt6-qtdeclarative-6.9.1-2.fc42.x86_64/src/qml/jsruntime/qv4runtime.cpp:1562
#27 0x00007f4d5f42c9c8 in ??? ()
#28 0x000055b5f1131240 in ??? ()
#29 0x0000000000000000 in ??? ()

I've just had the same crash (same backtrace) with Plasma 6.4.2 on openSUSE Tumbleweed. Though in my case in was a RenPy game, and it didn't freeze (I just closed it with Alt+F4). It also uses XWayland though. I tried to reproduce it again, but without success.

Looks similar to Bug 500749, but not exactly the same thing.

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

Sentry says this is currently the #4 most common Plasma crash. Raising priority here.

After fixing some other ones, it's now #3, or #2 if we exclude the current #1 crash which is in 3rd-party code. Raising priority again.

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

I'm not able to reproduce this at the moment in Plasma built from git-master with

1. A  Wine  Ren'py game - force close with kill -9
2. War Thunder from Steam - close with Alt F4

other potential reproducers from Sentry

- After closing Kingdom Come Deliverance
- After playing then closing DDNet
- Closing Guild Wars 2 running through Steam (or Stardew Valley, Cities Skylines 2, other games using Proton0
- Closed Linux native Euro Truck Simulator 2 that was started from Steam with "gamemoderun mangohud %command%". I closed ETS2 from the in game menu. 
- right clicking spotify's tray icon after having alt+f4'ed a fullscreened window

This is against plasma 6.4.

this should have been fixed by commit be417b4d3d0f5e6eb3c9c0f492aa031bc0d2d4d8 in plasma-workspace which sanified a lot the proxy model.

reopen only if the same backtrace (not similar symptoms, actually same bactrace in taskgroupingproxymodel) still happens on plasma 6.6 or later

There's a new crash report with the same backtrace in Plasma 6.7.3, unfortunately. Reopening.

Steps to reproduce from the duplicate:
> I was having a remote session on my PC to which I connected my dualsense controller via bluetooth. Since the controller was on battery, I connected it to the laptop via usb as well.

> After I finished my gaming session on the PC, plasma crashed, probably because of the sudden (re)appearence of a USB controller(?).

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

A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/6879

A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/6879

A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/6879

A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/6879

Any updates on the fix?

(In reply to Máté Farkas from comment #20)
> Any updates on the fix?

There's a merge request in progress to fix this, which is linked in the comments. You can follow that for progress.

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

A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/7053

Git commit 4a513cce1d320e368c665e54fa9aaf5307d11254 by David Edmundson.
Committed on 28/09/2026 at 08:51.
Pushed by davidedmundson into branch 'master'.

Fix the window mapping again

The idea of the current code is we have:
 - a launcher model
 - a startup model
 - a window model

we then:
 - concatenate these models
 - then filter them
 - then group them
 - then filter some out again in TasksModel

This last part is a bit sketchy. There is a goal that is if a launcher
exists for a window that is showing we should hide the launcher.

It's an unusual pattern for a filter model, when entry B gets inserted,
entry A should get removed.

The current code detects when a launcher is added, then emits
dataChanged in the filter model. Emitting dataChanged in another model
is very weird, we end up recursively getting back into dataChanged
handling from within a call handling dataChanged and the mapping gets
mangled.

Instead lets keep filtering in the filter model and avoid this incorrect
dataChanged to trigger a re-evaluation. We do it directly when the
source changes.

M  +58   -0    libtaskmanager/taskfilterproxymodel.cpp
M  +14   -0    libtaskmanager/taskfilterproxymodel.h
M  +5    -92   libtaskmanager/tasksmodel.cpp

https://invent.kde.org/plasma/plasma-workspace/-/commit/4a513cce1d320e368c665e54fa9aaf5307d11254

Git commit c2c8595237013330930a172063ece532ad782f74 by Nate Graham, on behalf of David Edmundson.
Committed on 30/09/2026 at 18:17.
Pushed by ngraham into branch 'Plasma/6.8'.

Fix the window mapping again

The idea of the current code is we have:
 - a launcher model
 - a startup model
 - a window model

we then:
 - concatenate these models
 - then filter them
 - then group them
 - then filter some out again in TasksModel

This last part is a bit sketchy. There is a goal that is if a launcher
exists for a window that is showing we should hide the launcher.

It's an unusual pattern for a filter model, when entry B gets inserted,
entry A should get removed.

The current code detects when a launcher is added, then emits
dataChanged in the filter model. Emitting dataChanged in another model
is very weird, we end up recursively getting back into dataChanged
handling from within a call handling dataChanged and the mapping gets
mangled.

Instead lets keep filtering in the filter model and avoid this incorrect
dataChanged to trigger a re-evaluation. We do it directly when the
source changes.


(cherry picked from commit c43e74c6d2879fea28717ac06a1e7dea72abf46b)

Co-authored-by: David Edmundson <kde@davidedmundson.co.uk>

M  +58   -0    libtaskmanager/taskfilterproxymodel.cpp
M  +14   -0    libtaskmanager/taskfilterproxymodel.h
M  +5    -92   libtaskmanager/tasksmodel.cpp

https://invent.kde.org/plasma/plasma-workspace/-/commit/c2c8595237013330930a172063ece532ad782f74