Created attachment 129597 [details] Plasmashell leak valgrind massif SUMMARY STEPS TO REPRODUCE 1. Just regularly using the system. OBSERVED RESULT System got sluggish. Viewing htop output, plasmashell was the top reserved-memory usage with 2.6GB (/8GB). EXPECTED RESULT Don't leak. SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: Arch Linux (available in About System) KDE Plasma Version: 5.19.1 KDE Frameworks Version: 5.71.0 Qt Version: 5.15.0 ADDITIONAL INFORMATION I saw https://bugs.kde.org/show_bug.cgi?id=403563 and https://bugs.kde.org/show_bug.cgi?id=393929#c17. You could say it's getting a little more "widespread". I attached my massif output for a 3 hour span where the heap grew to ~400MB from ~138MB.
Forgot to include another user's experience with the same release: https://bbs.archlinux.org/viewtopic.php?id=256543
Does removing the system monitor applets make that go away?
Ugh, I was hoping I wouldn't have to remove them. I had just customized them after the notable upgrade/change. I knew the thermal widget had an issue and was really surprised/pleased to see the new design. When I first booted up, before I made any changes, there was some wonky stuff happening. It got even worse when I tried to modify the widgets. I ended up removing all of them, then adding them back in and recustomizing them. Then this happened. I noticed the quickcharts mentioned in the visualizer. Anyway, before your response, I went ahead and --replaced plasmashell using heaptrack about an hour ago. And now I removed all of the widgets but I'm not replacing plasmashell again (still running under heaptrack). Maybe there will be a notable settling in the output from that first hour to maybe a few more hours I give it.
Created attachment 129634 [details] Memory Usage Chart Stuck For "Available". Uptime Is Always "0.0" Okay, this time I opted to let it go for over 24 hours. I ended it when it was ~1.4GB. When things looked steady/healthy WITHOUT the widgets, I re-added them ~5.5 hours later, where it looked to have increased comparatively slowly. Heaptrack also confirms libQuickCharts.so as being the largest holder of memory. Let me know if you still want the .zst file. It's 241MB. I've also attached a screenshot of my widget setup because there are a few issues. Let me know if you want me to make another bug(s) for them... Basically 1) the "Ava[i]lable"[sic] "Memory Usage" line isn't moving. At some point, it just stops. 2) Long names cut off. It would be nice to allow the user to customize the data field names like "/home read speed" instead of "Read data device dm..." which got cut off 3) "System uptime" always shows as 0.0. 4) (not in screenshot) There are 2 "Uptime" "sensors". First is the lone sensor in the list of folder/categories when you go to the "Sensors Details". The second is when you go under the "System->Uptime" category which is labeled as "System uptime" which also shows as 0.00.
(In reply to vindicator from comment #1) > Forgot to include another user's experience with the same release: > https://bbs.archlinux.org/viewtopic.php?id=256543 Uh, just realized I'm that "another user" ;) I wanted to add some observations: * This didn't happen for me before plasma-5.19 * I was running Qt-5.15.0 with plasma-5.18 without issues for some time * The initial memory usage of a freshly booted system is (significantly) higher with plasma-5.19 than any plasma before * It seems to be no real memory leak but really bad memory handling, I saw memory usage drop to even below initial usage (initially plasmashell uses ~5%, saw it go down to ~3%. yesterday I was ~20%, now after waking up from suspend I am at ~9%). I think this might be some issue with garbage collection in the script engine. Especially the last point makes me think that. No idea why I got hit by this just now, but it might be triggered by the new system monitor applet. I do not have any other widget on the desktop, never had. Just memory, network and cpu monitor. Panel is pretty default, too.
New information was added with recent comments; changing status for investigation.
Created attachment 129804 [details] screenshot of top + sensor applets I'm a little bit unsure where the memory goes. I added up all %MEM, makes 21.5%, equals 812MiB. But it says USED=1410.9MiB. Are these missing 600MiB kernel memory? xrestop showed kwin as the only big consumer with little less than 30MB. As you can see no other applications are running currently, so bare desktop + one urxvt window. Also what exactly is that 1.8 GiB the memory applet is showing for Allocated Memory? Neither used nor used+buff/cache match. The old plasmoid showed "used" mem. Could it be that at least part of the leaked memory is GPU memory? I have an intel iGPU that allocates RAM memory (no dedicated memory on GPU). I also experienced quite some GUI lag, even with just a freshly opened firefox + urxvt + tmux - so could it be that GPU memory doesn't get freed? I now rebooted as the system got quite unusable (laptop after 6 days of usage). In case you want some additional info it might take some time.
On Arch Linux too, same issue. With a few third party widgets and system monitor, plasmashell uses 3GiB after 3 days. I removed third party widgets, only keeping native, "out of the box" widgets (plus global menu) Here's a screenshot https://abistodenas.eu/nextcloud/s/ooQm3GYmBbys974/preview With this configuration plasmashell grows to 800MiB after 3 days. I don't know which logs are relevant, but happy to provide anything useful.
Bump x3. I'd appreciate if this bug takes priority - it might be causing other accidental threads being created in relation to memory leaks and mistaking side effects in other places (such as I did with plasma widgets). It makes it impossible to keep a desktop linux distro running KDE for several days and it's making the desktop environment give a really poor impression and experience.
Created attachment 146250 [details] htop plasmashell 635MB Name : plasma-workspace Version : 5.23.5-2 < 2 weeks of using heaptrack and plasmashell process climbed pass the 630MB used by heaptrack. Attaching 3 screenshots.
Created attachment 146251 [details] heaptrack caller/callee
Created attachment 146252 [details] heaptrack bottom/up
Those heaptrack logs show all memory being lost in textures in the Intel driver. There are two options at this point: - We are leaking textures and not telling the graphics driver to cleanup - Mesa is leaking textures Given we don't have any other reports on other platforms I would err towards option 2. If you can test if upgrading/downgrading mesa makes a difference that would be good.
I'll leave this here, regarding that thought: https://gitlab.freedesktop.org/drm/intel/-/issues/2924#note_1324171