[plasmashell] [Bug 517888] Huge memory leak in plasmashell caused by calendar update

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.