523046 2026-07-14 12:53:16 +0000 plasmashell crashes (SIGABRT) in PlasmaTheme::syncWindow() during QObject::connect, triggered by Akonadi calendar removal cascading through digital-clock delegate rebuild 2026-07-14 17:49:11 +0000 1 1 4 Plasma plasmashell Digital Clock widget 6.7.2 Fedora RPMs Linux UNCONFIRMED https://bugs.kde.org/show_bug.cgi?id=511028 efficiency-and-performance NOR crash 1.0 0 feher.erik plasma-bugs-null kdedev 0 oldest_to_newest 2531608 0 feher.erik 2026-07-14 12:53:16 +0000 Summary: plasmashell crashes with SIGABRT while constructing a new PlasmaTheme (Kirigami platform theme) during QObject::connect() inside syncWindow(). The crash is triggered while an Akonadi calendar item deletion (AkonadiPimDataSource::onSettingsChanged → EventModel::removeCalendar → IncidenceChanger::deleteFinished) propagates through KCalendarCore::Calendar::notifyIncidenceAboutToBeDeleted, causing the digital-clock applet's QML calendar delegate model to reset and rebuild, which incubates a new delegate that attaches a Kirigami::Platform::PlatformTheme. Prior to the crash (starting ~3 minutes earlier), the digital-clock config QML (configAppearance.qml) and the PIM-events calendar plugin config QML (PimEventsConfig.qml) logged dozens of SimpleKCM does not have a property called cfg_* errors — a KCM/config-QML property mismatch that may be a related or contributing regression. Versions: Fedora Rawhide (F45), plasma-workspace 6.7.2-2.fc45, libplasma 6.7.2-1.fc45, akonadi-calendar 26.04.3-1.fc45, kf6-kcrash 6.28.0-1.fc45, Wayland session Backtrace (crashing thread, main): KCrash::defaultCrashHandler QObjectPrivate::connectImpl / QObject::connectImpl PlasmaTheme::syncWindow() [KirigamiPlasmaStyle.so] PlasmaTheme::PlasmaTheme(QObject*) Plugin::createPlatformTheme(QObject*) Kirigami::Platform::PlatformTheme::qmlAttachedProperties ... [QML delegate incubation chain] ... QQmlDelegateModelPrivate::emitChanges QQmlDelegateModel::handleModelReset DaysModel::onEventRemoved EventPluginsManager::eventRemoved CalendarEvents::CalendarEventsPlugin::eventRemoved PimEventsPlugin::calendarIncidenceAboutToBeDeleted KCalendarCore::Calendar::notifyIncidenceAboutToBeDeleted Akonadi::CalendarBasePrivate::internalRemove Akonadi::CalendarBasePrivate::slotDeleteFinished Akonadi::IncidenceChanger::deleteFinished EventModel::removeCalendar AkonadiPimDataSource::onSettingsChanged To reproduce (best guess): Have the digital clock's calendar view open with the PIM Events (Akonadi) calendar plugin enabled, then remove/delete a calendar or change its settings so Akonadi fires a delete-finished signal while the applet is active. Additional observation: plasmashell's memory usage climbed to a 10.8G peak with an unusually large number of memory mappings (core file had 23,713 program headers) before the crash — may indicate an unrelated leak worth separate investigation. 2531643 1 kdedev 2026-07-14 16:04:57 +0000 Thanks for the bug report, and the detailed analysis. That's very helpful. The backtrace looks a lot like bug 511028, which fixed a similar crash in 6.7.0. I'm not able to reproduce this with Plasma built from git-master by changing a calendar's properties in KOrganizer or deleting an event while the Digital Clock widget is open I'll leave this open so others can try to reproduce 2531673 2 feher.erik 2026-07-14 17:49:11 +0000 (In reply to TraceyC from comment #1) > Thanks for the bug report, and the detailed analysis. That's very helpful. > > The backtrace looks a lot like bug 511028, which fixed a similar crash in > 6.7.0. > I'm not able to reproduce this with Plasma built from git-master by changing > a calendar's properties in KOrganizer or deleting an event while the Digital > Clock widget is open > > I'll leave this open so others can try to reproduce Thanks for looking into this, TraceyC. I can offer a precise, simple reproduction. My crash was not caused by deleting a calendar or an event — it happened from a routine settings change: Right-click Digital Clock → Configure Digital Clock... Go to Calendar Events Untick one of the enabled calendars (in my case, a secondary Google calendar under Calendar Events) Click Apply That's it — no dragging, no deleting events, no removing Akonadi resources. Just unchecking a calendar checkbox and applying. Backtrace confirms the same PlasmaTheme::syncWindow() → QObject::connect crash path as 511028, but reached via disabling a calendar plugin rather than dragging the calendar view: AkonadiPimDataSource::onSettingsChanged EventModel::removeCalendar Akonadi::IncidenceChanger::deleteFinished Akonadi::CalendarBasePrivate::slotDeleteFinished Akonadi::CalendarBasePrivate::internalRemove KCalendarCore::Calendar::notifyIncidenceAboutToBeDeleted PimEventsPlugin::calendarIncidenceAboutToBeDeleted CalendarEvents::CalendarEventsPlugin::eventRemoved EventPluginsManager::eventRemoved DaysModel::onEventRemoved QAbstractItemModel::modelReset QQmlDelegateModel::handleModelReset ... [QML delegate incubation rebuild] ... Kirigami::Platform::PlatformTheme::qmlAttachedProperties Plugin::createPlatformTheme PlasmaTheme::PlasmaTheme PlasmaTheme::syncWindow QObject::connectImpl KCrash::defaultCrashHandler AkonadiPimDataSource::onSettingsChanged (which fires when the enabled-calendars config changes) calls EventModel::removeCalendar for the deselected calendar, and that removal cascades through the same delegate-rebuild path that reaches syncWindow(). Given the trigger here is simply unchecking a calendar in settings, this should be trivially reproducible. Given this reaches syncWindow() via a config-change-driven delegate rebuild rather than rapid calendar dragging, the 6.7.0 fix for 511028 likely does not cover this path. Note: GDB 17.2 on this system crashes when processing the core file (both with and without debuginfod), so I'm unable to attach a standard GDB backtrace. The trace above comes from eu-stack plus systemd-coredump's own automated backtrace, both of which agree. Happy to attach the raw core file or .ini crash metadata if useful, or file the GDB issue separately. Separately — unrelated but co-occurring — I saw a wave of SimpleKCM does not have a property called cfg_* and PimEventsConfig does not have a property called cfg_* errors in the minutes before the crash, from configAppearance.qml and PimEventsConfig.qml. Not sure if related, but flagging in case it's a symptom of the same underlying config/plugin state issue.