Hi Marco. Thanks for your very detailed report.
A few things about it: Marco Möller - 22.02.25, 10:57:15 MEZ: > After quitting Akregator, this app is not fully removing its footprint > form the memory but at least leaving a kio_http_cache_cleaner process > behind. That kio_http_cache_cleaner process isn't categorized in the > process tree for usr/bin/akregator but appears as an independent > process, though. However, in the 'System Monitor' app on page > 'Applications' it remains listed as some app with title "Akregator". The > memory usage of the residual app entry is there stated to be 2.8 MB. I newer cared about kio related processes lingering around on a Plasma based desktop system. KIO – KDE Input / Output – is a way to out source I/O related activity of various kinds into separate processes. As I do not know the exact policy on when those processes quit, I never cared about them. > I wouldn't have the knowledge to figure out if the Akregator app,the > kio_http_cache_cleaner, or even the System Monitor app is buggy, how or > where the 115 MB gap between process tree footprint and reported > Application footprint is caused, and am also not sure where in the bug > tracker to place this bug report. It may very well be that this all just works as designed. It may be that the kio_http_cache_cleaner process is kept around for later use for a while. Memory analysis is hard. In order to do it accurately you need to understand how the Linux virtual memory subsystem works including the difference between virtual address space and actually allocated (resident) memory, on demand paging as well as how memory is shared between different processes for example by using the same shared objects (PSS – Proportional Set Size) just to name a few of the concepts. (I teach this stuff in Linux Performance analysis and tuning courses.) > So, I decided to leave this message here in the hope that some skilled > KDE developer find it and pick it up for improving KDE. By the way, > Thanks for KDE! This is no KDE developer mailing list. It is the Debian KDE *user* mailing list. Some Debian/Ubuntu KDE/Qt package maintainers are members of the list, but I doubt you would be reaching a lot of KDE developers this way. > Operating System: Debian GNU/Linux 12 > KDE Plasma Version: 5.27.5 > KDE Frameworks Version: 5.103.0 > Qt Version: 5.15.8 > Kernel Version: 6.12.9+bpo-amd64 (64-bit) > Graphics Platform: X11 This is to old. This is *way* to old for an upstream bug report. If you want to make your work useful for KDE developers you need to test all of this with recent Plasma 6 / KF 6 / Qt 6 versions. Which basically means using Debian Unstable / Testing at this time *or* using some live distribution with up to date versions like KDE Neon. I'd also not report it to the Debian bug tracker. Debian 13 aka Trixie with a greatly updated Plasma/KDE Gear/KF/Qt stack is around the corner. I do not think Debian/Ubuntu Qt/KDE package maintainers could do much about your report for a version that has moved or is moving out of upstream support. I use Debian Unstable Plasma/KDE stuff through Devuan Ceres. And from a quick test I do not see any cache cleaner processes, however I have a bunch of kio_http processes lurking around and that is what I expect. However after just a few minutes any Akregator related kio_http processes are gone again. Whether I would see some cache cleaner processes after a while, not sure. Still not seeing any at the moment. However… again… I would not care. As long as they not grabbing memory like crazy I'd rather just ignore those processes. Then before reporting an issue, it may be better to raise this with an upstream KDE mailing list. Cause again it may just be working as intended. Without further research myself I am not that sure at the moment which one may be a good one to start with. But you could also report an issue with the upstream bug tracker. Could take a while for them to respond however. KDE PIM developer team is still understaffed. To conclude: Kudos for all the work you put into analyzing this probable (!) memory foot print issue. However I think your current report is not really all that actionable and does not address the right audience here. So if you are serious about this memory issue, I suggest you review some of the suggestions I made. You'd need to invest some additional work and a careful approach on where to report in order to make this useful for upstream developers. Or you might just ignore it in case you have enough memory. :) I am not really aware of a serious memory leak withing Akregator and I use it with more than 100 of feeds and keep it open for hours and days in between. However… this laptop has 32 GiB of RAM and I eventually close it every now and then. Actually those 32 GiB of RAM is more I ever need at the moment. So if it would be just leaking a few MiB or even a few 100 MiB I might not even notice without looking. Best, -- Martin
