https://bugs.kde.org/show_bug.cgi?id=521060
Jerôme Pouiller <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #2 from Jerôme Pouiller <[email protected]> --- I can confirm this on a released version, not only master: kalendarac 24.12.3 (Debian 13 "trixie", akonadi-calendar 4:24.12.3-1, Qt 6.8.2, KF 6.13.0, Plasma 6.3.6, Wayland). After I ran an agent on the code, it seems has been fixed as a side effect of commit 9bc85e48 "calendar-plugin: Fix updating items" (2026-10-08), which moved ETMCalendarPrivate::updateItem() into CalendarBasePrivate::internalUpdate() and added mItemsByCollection.remove(seenItem.storageCollectionId(), seenItem) before re-inserting the item. I will try to test the fix. FYI, on my side, after 18 days of uptime, the kalendarac process alone (figures from /proc/<pid>, no Akonadi process included) was at: VmRSS: 1264888 kB RssAnon: 1248884 kB RssFile: 16004 kB VmSwap: 19568 kB 1206672 kB of RssAnon in the [heap] mapping (from /proc/<pid>/smaps) A freshly restarted instance is at RssAnon 57412 kB (VmRSS 186100 kB), so the leaking process had grown to ~22x its baseline, about 3 MB/hour on average. The calendars are one Akonadi iCal resource, one Google resource and the birthdays resource; the Google one syncs periodically, which matches the "frequent item updates" trigger described above. The leaked process ended up contributing to a global OOM situation on this machine (it appeared with 311338 resident pages in the OOM killer report). -- You are receiving this mail because: You are watching all bug changes.
