After the most recent system updates I encounter a heavy memory leak which lets applications like Chromium, Chrome, Firefox, Maven builds etc. run out of memory. It is jard for me to analyze, but I try to collect the necessary information. OS: OpenSUSE Tumbleweed 20151209 uname -a: Linux rkrell 4.3.0-2-default #1 SMP PREEMPT Sat Nov 14 16:19:19 UTC 2015 (734b32c) x86_64 x86_64 x86_64 GNU/Linux I opened the Gnome System Monitor to get an idea of a suspicious application - the most common one for all failure situations which consumes most memory is plasmashell: - Virtual Memory: 10 GB - Resident Memory: 435,2 MB - Shared Memory 204,4 MB - X-Server memory: 2,3 MB followed by baloo: - Virtual Memory: 5,3 GB - Resident Memory: 88,5 MB - Shared Memory 17,2 MB - X-Server memory: 0 kBytes Several weeks ago with previous KDE versions this didn't happen. I'll append several output I get from my system, if you're interested please tell me what else to provide, I'm not sure. Reproducible: Always Steps to Reproduce: 1. Logon to KDE 2. Open Chromium/Chrome (or whatever app usually consuming a bit more memory) Actual Results: Most of the tabs of about 20 open tabs don't open.
Created attachment 96058 [details] cat /proc/`pidof plasmashell`/smaps (output)
Created attachment 96059 [details] cat /proc/`pidof baloo_file`/smaps (output)
KDE versions: - KDE Releases Frameworks: 5.16.0 - KDE Releases Applications 15.08.3 - Plasma: 5.4.3
- Resident Memory: 435,2 MB That's not a huge amount. and "virtual memory" isn't actually a measure of anything useful. Sorry, but this really doesn't give me any information at all. You can try running plasmashell in valgrind and see if that reports anything.
I was hit by the same issue, plasma shell is taking ~10.5GB of virtual memory. I don't know if this is an issue or not but I've attached info from memstat and smaps. You can see from them that 5242880k(5242880k): /home/darostol/.local/share/baloo/index 1789 is taking ~5GB of virtual memory.
Created attachment 96354 [details] Plasmashell memstat output
Created attachment 96355 [details] Plasmashell smaps output
Just one more hint, running the other apps (Firefox, Chromium) in Gnome 3.18.2 on the same system initially reported works without memory failures, it depends on the KDE environment. From what I reported there was also the big baloo index of 5 GB.
From the user comments, https://bugs.kde.org/show_bug.cgi?id=344879 looks very similar to me.
@David: Can you please give me a hint how to use valgrind for this use case, it has quite a lot of command line options. I can try this, but I don't want to spam this report with useless information. Just a short "how to", please, what to kill before and how to measure leaks here? BTW: Using the nvidia proprietary driver 352.63 for compositing, on a HP ZBook 15 G2.
Created attachment 96358 [details] Output of killall plasmashell; kstart valgrind --error-limit=no --leak-check=full --show-leak-kinds=all --log-file=/tmp/plasmashell-valgrind.log plasmashell Added the output of killall plasmashell; kstart valgrind --error-limit=no --leak-check=full --show-leak-kinds=all --log-file=/tmp/Xorg-valgrind.log plasmashell. From my point of view doesn't still show the leak in the dimensions described.
Launching chromium in valgrind using the same command line options ends in: ==16979== LEAK SUMMARY: ==16979== definitely lost: 0 bytes in 0 blocks ==16979== indirectly lost: 0 bytes in 0 blocks ==16979== possibly lost: 0 bytes in 0 blocks ==16979== still reachable: 108,483 bytes in 1,293 blocks ==16979== suppressed: 0 bytes in 0 blocks but just about 10 of 30 open tabs open, the rest of the processes crash because it gets no resources. This does not happen in Gnome 3.18.2 at all.
Created attachment 96359 [details] Output of killall baloo_file; kstart valgrind --error-limit=no --leak-check=full --show-leak-kinds=all --log-file=/tmp/baloo_file-valgrind.log baloo_file BTW: Baloo crashes all the time after a while (DrKonqui), not just over valgrind.
Please just check whether the additional information gives you any useful information. Or just send a hint. I just see the problem just existing in KDE and offer help for finding the reason. If not possible, feel free to close this again. Thank you.
Good news: The problem disappeared for me in PLasma 5.5.1. Marking this resolved.