https://bugs.kde.org/show_bug.cgi?id=526769
Bug ID: 526769
Summary: plasmashell uses several GB of memory and gets
OOM-killed when a calendar plugin removes many events
at once (DaysModel resets the model once per removed
event)
Classification: Plasma
Product: plasmashell
Version First 6.7.5
Reported In:
Platform: Fedora RPMs
OS: Linux
Status: REPORTED
Severity: crash
Priority: NOR
Component: Digital Clock widget
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: 1.0
SUMMARY
When the Digital Clock calendar has the PIM Events plugin enabled and an
Akonadi calendar replaces all of its events at once, plasmashell grows from
~0.5 GB to several GB within about 20 seconds and is killed by the OOM killer.
Once it reached 22 GB and froze the whole system before the OOM killer stepped
in.
The trigger in my case is a school timetable (remote iCal feed, 176 VEVENTs)
loaded through an Akonadi iCal file resource. The feed generates new UID,
CREATED and LAST-MODIFIED values for every event on every download. So every
reload removes all 176 items and adds 176 new ones. A reload with stable UIDs
causes no growth at all.
STEPS TO REPRODUCE
1. Create an Akonadi "ICal Calendar File" resource on a local .ics file with
~150+ events that fall partly in the visible month.
2. Enable that calendar in the Digital Clock's PIM Events plugin, and open the
clock popup once so the calendar view exists.
3. Replace the .ics file with a copy where every UID is different (same events
otherwise).
OBSERVED RESULT
plasmashell stops responding and its memory grows by ~170 MB/s until it is
OOM-killed.
EXPECTED RESULT
The calendar updates once. Memory use doesn't change noticeably.
ANALYSIS
Backtrace while memory is growing (debug symbols, QV4_FORCE_INTERPRETER=1):
EventModel itemRemoved lambda (kdepim-addons eventmodel.cpp:75)
-> Akonadi::CalendarBasePrivate::slotDeleteFinished -> internalRemove
-> PimEventsPlugin::calendarIncidenceAboutToBeDeleted -> eventRemoved(uid)
-> DaysModel::onEventRemoved -> endResetModel() (daysmodel.cpp:269)
-> QQmlDelegateModel::handleModelReset -> QQuickRepeater::modelUpdated
-> incubating new DayDelegates -> nested Repeater/DelegateModel for the
event dots
-> Kirigami.Theme attached object per new item
DaysModel::onEventRemoved() does beginResetModel()/endResetModel() for every
single uid. It even does that when the uid isn't in the model. The removals
arrive synchronously one after another, so the month view rebuilds all 42 day
delegates and their event-indicator delegates 176 times, and the event loop
never gets a turn to clean up the old ones in between.
I reproduced it outside plasmashell with a small QML harness:
org.kde.plasma.workspace.calendar MonthView plus EventPluginsManager with
"pimevents", against a test Akonadi resource.
- Full MonthView: 286 MiB to 1.9 GiB in 11 s, then killed by a 2 GiB cgroup
limit. The QML event loop is blocked the whole time.
- Only Calendar/DaysModel with the same plugin, no view: flat at 225 MiB. All
176 removals and 47 additions are processed in under a second.
So the plugin and akonadi-calendar handle the burst fine; the cost comes from
the per-removal model reset in DaysModel.
FIX
Merge request: <link>. It queues removed uids and applies them in one reset
from a queued call. Pending removals are applied before new or modified data,
so remove-then-re-add for moved events keeps working. If none of the removed
uids are shown, there's no reset. With the patch, the same test peaks at 301
MiB and finishes immediately. The events shown are unchanged: per-day event
counts in the view are identical before and after a UID swap, and moving one
event (same UID) shifts it by exactly one day.
This is likely also the root cause of bug 493415 (plasmashell freezes when
removing an Akonadi calendar shown in the Digital Clock): removing a collection
makes the PIM Events plugin report every event as removed, which goes through
the same per-event reset.
Side note (separate issue in kdepim-addons): EventDataIdVisitor emits
eventRemoved for every non-recurring incidence, including those outside the
visible date range (176 signals here, while only 47 events are shown).
The analysis, reproducer and patch were developed with help from an AI
assistant; I reproduced and verified all results on my own system.
SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Fedora 44, kernel 7.2.8, Wayland
KDE Plasma Version: 6.7.5
KDE Frameworks Version: 6.30.0
Qt Version: 6.11.2
kdepim-addons / akonadi-calendar: 26.08.1
Graphics: Intel + NVIDIA hybrid (Lenovo ThinkBook 16p G5)
--
You are receiving this mail because:
You are watching all bug changes.
