https://bugs.kde.org/show_bug.cgi?id=517888
Senjin the Dragon <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 Status|REPORTED |CONFIRMED CC| |[email protected] --- Comment #5 from Senjin the Dragon <[email protected]> --- **Environment:** Plasma 6.7.4, KF6 6.28.0, Qt 6.11.1, Arch-based (Garuda Linux), Wayland, digital-clock calendar widget with an Akonadi CalDAV resource (Nextcloud, `akonadi_davgroupware_resource_0`, `refreshInterval=30`). I can confirm this bug and have live, symbolized allocation-trace evidence pinning down the exact mechanism, which might help move this forward. **Reproduction pattern:** Over ~2.5 weeks (2026-07-30 to 2026-08-14) I logged 15 separate plasmashell memory-ballooning incidents, all with the same signature: sudden onset from a flat baseline within a 10-20 minute window, cgroup memory climbing to several GB, system swap exhausted, plasmashell throttled (never OOM-killed outright). Onset never required any user interaction — it happened just as often overnight while the desktop was idle. **Root cause, confirmed via BCC's `memleak` (uprobe-based allocation tracer, doesn't touch the allocator so it's safe to run against a live plasmashell — `heaptrack`'s LD_PRELOAD approach reproducibly corrupted the process's heap on my system, for what it's worth, so I'd avoid recommending that as a diagnostic method here):** Captured a live occurrence with a properly-sized trace (1.5M stack storage, needed — the default `--stack-storage-size` overflows well before it captures the full picture on this workload). The outstanding-allocation total for calendar-tagged stacks jumped from ~500KB to ~125MB in a single 15-minute snapshot window, accounting for nearly the entire memory spike. Cross-referenced against my Nextcloud server's own access log: a real CalDAV sync (`PROPFIND`/`REPORT` against `/remote.php/dav/calendars/...`) landed at the very start of that exact window. The call chain, seen repeatedly and consistently across occurrences: ``` Akonadi::Monitor::itemRemoved → Akonadi::MonitorPrivate::emitItemsNotification → CalendarEvents::eventRemoved → (digital-clock calendar plugin, libcalendarplugin.so) → QAbstractItemModel::endResetModel() → QQmlDelegateModel::handleModelReset() → QQuickRepeater::modelUpdated() → QQuickRepeater::regenerate() [clear() + full rebuild via QQmlObjectCreator] ``` In the captured occurrence, this single event produced ~712,000 individual allocations across 88 distinct call stacks (QML object creation, `QQmlPropertyBinding::create`, `QQuickRectangle` construction, etc.) — all from `QQuickRepeater::regenerate()` tearing down and recreating the *entire* delegate tree on a single Akonadi item removal, rather than an incremental update for just the changed item. That scale is consistent with a full model reset firing on every single sync-triggered removal, not a targeted per-item update. **Fix that resolved it for me:** removed Akonadi and the whole PIM stack entirely (it was only installed for this calendar-widget integration, no other PIM apps in use). Zero recurrences since. Not a fix for the actual bug obviously, just confirms the mechanism and gives a clean way to test whether it's this code path specifically. Happy to share the raw `memleak` trace data or more detail on methodology if useful — the timing correlation (sync timestamp vs. allocation explosion) and the full call stacks are the most concrete pieces of evidence I have. -- You are receiving this mail because: You are watching all bug changes.
