Created attachment 129717 [details] Top-down A memory leak is present in akonadi-server versions ranging from 18.08 to 20.04: whenever KMail rechecks all folders of my Google IMAP account, memory just grows but never shrinks. I've created heaptrack summaries both for 18.04 and 20.04 of the leak which show that the server starts eating memory. Last time it went up to 12 GB when I stopped it. You can reach the pictures showing the memory occupation and a backtrace file here: https://mega.nz/#F!RQ4iBSRT!DmHq4qoDKpuVyewuAmazsA I attach two of pictures for 20.04 here as well. For 20.04 I have the heaptrack file stored locally which is 14 GB in size, but I can upload it in case you need it. It's not a classical memory leak since everything will be freed up upon exit however I still consider a valid one.
Created attachment 129718 [details] Flame graph
Thanks for the detailed data. Could you please share the heaptrack file for the 20.04 measurements? I'd like to investigate it in more depth.
Never mind, I found the problem :)
I take it back, it would still be useful to get the 20.04 heaptrack data, from the screenshots it seems to have better quality. You could try changing the compression algo (use .xz instead of .gz for instance). If you need some place where to upload such a huge file, I can give you upload access directly to my server.
Could you please check that you have the "Debugger" disabled in Akonadi Console? When the "Debugger" option is enabled, it causes the Server to generate a lots of debugging string data and send them over dbus. The "Debugger" option gets persisted in Akonadi Server for now, so even if you close Akonadi Console, the Akonadi Server will continue generating the data. I'll adjust the code to not persist the debugger accross Akonadi restarts. Anyway, that's what I see in the 20.04 screenshots, but that's just lots of temporary allocations, not the leaks. The leaks visible in the 18.04 heaptrack are related to QueryCache, which has been overhauled in 20.04. So I suspect what you are seeing on 18.04 is already fixed, and what you are seeing in 20.04 is either related to the Debugger being enabled and/or the real culprit is not shown on the screenshots.
Nice catch, debugging was on; turned it off. I'll recompress its default .zst (ZStandard) into .xz and upload it into the aforementioned mega.nz directory (just to have everything in one place). I'll try to enable parallel decompression ability so you can use -T0 for unxz. I'll notify you as soon as I've finished.
On a second thought, I've decided zst is good enough, especially even after 220 GB it was still decompressing... I could've piped into xz but then you'd have to convert it again back for heaptrack_gui so I decided I leave it untouched. You can find the file on the link in the original post. It can take some time until it's loaded into the program.
It seems, that even after turning off the debug output this issue still persists, unfortunately. Tested with 5.15.0 (20.08.0).
The issue appears to be that QEventLoop in line 192 of server/connection.cpp never gets its signal/slot connections cleaned up. I would assume RAII would take care of that by the end of the scope at line 197, but it does not, so a TON of QT signal/slot connection objects linger around forever. I was able to fix it by simply calling the corresponding "disconnect" after the "loop.exec()" for each of the three connects. This way the QObject connections go away and so does the memory leak. I don't have a developer account, so i'm not sure how to submit the merge request, but i'm trying to get it through.
Created merge request https://invent.kde.org/pim/akonadi/-/merge_requests/95