https://bugs.kde.org/show_bug.cgi?id=521757
[email protected] changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bugs.overpass613@passinbox. | |com --- Comment #1 from [email protected] --- Maybe i've found the Root cause of the CPU/SQLite thrashing, found via heaptrack while investigating a related plasmashell freeze/leak: every call to KActivities::Stats::ResultWatcher::resultRemoved() re-runs a full SQLite query from scratch (ResultModelPrivate::fetch() -> new ResultSet -> QSQLiteResult::prepare/reset) instead of updating incrementally. In a 14-minute heaptrack session this call chain alone accounted for 139051509 allocation calls. Full call stack: KActivities::Stats::ResultWatcher::resultRemoved(QString const&) -> KActivities::Stats::ResultModelPrivate::fetch(int, int) -> KActivities::Stats::ResultSet::ResultSet(KActivities::Stats::Query) -> QSQLiteResult::prepare()/reset() -> sqlite3 parse+exec -> malloc On my system (3 panels, each with a Kicker "frequently used" widget wired to KActivitiesStats) this also caused plasmashell's main thread to get stuck for long periods inside glibc's allocator (systrim/sbrk) while freeing the resulting QSqlQuery objects, eventually leading to plasma-plasmashell.service being killed by the timeout watchdog. RSS grew 70-440MB/minute while this was happening. Workaround that fixed it completely for me: System Settings -> Privacy -> disable "Track application and file usage" (org.kde.ActivityManager. Resources.Scoring). RSS went flat immediately after. Versions: Plasma 6.7.4, KDE Frameworks 6.29.0, Qt 6.11.1, Fedora 44, Wayland. -- You are receiving this mail because: You are watching all bug changes.
