Created attachment 159983 [details] Memory Leak Graph, running x11, reboot, running wayland plasma SUMMARY After switching back to testing using wayland over x, I noticed my system suddenly using all 128gb of ram and going into swap. Plasmashell is consuming all of the memory, and I have to restart back to sddm. STEPS TO REPRODUCE 1. Log into Plasma Wayland session from x, start desktop 2. Start normal use (browsers, gaming, zoom, libreoffice) OBSERVED RESULT Within 2 days, all 128gb of my ram is consumed of what is left by plasmashell process. Restarting the session is necessary. EXPECTED RESULT I normally operate weeks/months without reboot with x11, and have with wayland on earlier 5.27.1 or so, but since last upgrade(s) and testing with 5.27.5 and .6 now, there is an extreme memory leak directly in plasmashell. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Arch Linux, 6.3.9 kernel, nvidia 535.54.03, wayland 1.22.0 KDE Plasma Version: 5.27.6 KDE Frameworks Version: 5.107.0 Qt Version: qt5-5.15.10 System uses a large 11520x2160p frame buffer with 3x 4k displays, has caused even x11 issues earlier kde5, but lately not a problem over time with x11 on the 3080rtx gpu, only with wayland. ADDITIONAL INFORMATION With plasma wayland session or x11 (both same), I use NO desktop widgets, only the default taskbar, k menu, systray, and latte-dock with various widgets loaded there. The plasmashell process itself is consuming the memory from htop observation. I had been using wayland for some weeks a few months ago without issue, went back to xorg for a bit after some odd crashes, only this last week trying wayland again to now observe these. I added my desktop to librenms for snmp polling to observe/document the memory use as well, will include this of the past week after using xorg (normal use), and then switching back to wayland observing the drastic leak. I'm willing to provide any requested info, and willing to run with valgrind if possible, not sure the best way to do this and actually use the desktop.
So this is still happening, and very much related to 3d activity, but otherwise without even still continues to climb steadily either way. It seems without gaming or 3d applications it sinks about 10gb of ram into plasma per day, but running various games or persistent gl/vulkan functions vastly increase this, using my 128gb in plasmashell within two days to need to reset the user session. Using wayland with plasma, I get weird artifacting in transparencies like the title bars of windows always, that show a mouse moving over it over and over - it seems to be collecting "fragments" of things somehow, caching or otherwise using them, and not releasing them. Any sort of dynamic graphics exemplifies this to the point of memory starts climbing the more active it is. Various games opengl or vulkan seem to cause memory use of different levels to grow in plasmashell, but they certainly never reduce along the way. I suspect windows snapshot caching, but not sure how to disable globally just to see if the system behaves. My system and configuration is not particularly unique other than maybe the resolution/displays, I'd like to think I'm not the only one seeing this as prevalent as it is. Combined with things like zoom still not working properly with wayland or a working screen locker, makes it really hard to want to keep with it as the "future" still. I'm trying to stick with wayland, but having to restart my desktop every few days due to a memory leak in kde/wayland is killing me.
Thank you for the bug report. Unfortunately we were not able to get to it yet. Can we ask you to please check if this is still an issue with Plasma 6.2?
🐛🧹 ⚠️ This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information, then set the bug status to REPORTED. If there is no change for at least 30 days, it will be automatically closed as RESOLVED WORKSFORME. For more information about our bug triaging procedures, please read https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging. Thank you for helping us make KDE software even better for everyone!
Created attachment 177731 [details] plot of memory usage of plasmashell I'm seeing a similar issue. Attached is the plot of memory usage of plasmashell in the past 12 hours. X-axis is time and y-axis is RSS usage in KB. When I'm away from keyboard (2:30 - 7:00, 8:30 - 13:00), the memory usage is almost constant. As long as I'm using the computer (just basic open/close/switch windows. didn't run any large 3D applications), the memory usage keeps growing. There were a number of times my system freezes due to plasmashell eating too much RAM. This starts to happen since I switched to wayland from x11.
Thanks for confirming
This has stopped happening to me in the past week. I don't remember any changes I made despite regular archlinux upgrade. Maybe this was fixed in the 6.3.0 -> 6.3.1 upgrade.
Great news. How about you, Michael?
Created attachment 179130 [details] htop, ntop, btop of high memory in plasma 6.3.2 Hi Nate, I've not used 5.27 since early last year, I'm up to 6.3.2 on arch, and just started using wayland again a few weeks ago off and on. That said, looking right now it's being a chonk and hogging around 45gig of my 128 and 1.3gig gpu vram, which great I've got it, but I suppose anyone with less is going to have a rough time... I was seeing a bit of this using xorg the past few weeks on 6.2.5, but it was both plasma and xorg hogging each some ~30gig of ram. Both are fairly stable running at that, but would be nice if plasma weren't such a hog. See attached png for usage from htop/btop/nvtop.
Sounds like the leak itself is fixed, but typical idle usage remains higher than desired. Would that be an accurate statement, Michael?
(In reply to Nate Graham from comment #9) > Sounds like the leak itself is fixed, but typical idle usage remains higher > than desired. Would that be an accurate statement, Michael? Yeah, definitely ugly. By last night bedtime it hit 90gb use and sits there now. I kicked of a heaptrack on plasma to see what is up, but my first time using, and it's been running for about about 7 hours to now producing about 150mb file so far. I killed most everything else to try to buy it room before it starts oom'ing things, hoping to get something out of heaptrack that is useful to you guys. If this ends up being partial, what sort of expectation is there for how long to leave heaptrack running, and how long *should* it run for something like plasma soaking up ~90gb of ram?
Created attachment 179151 [details] heaptrack of plasma @ 93gib used - summary Did some more rtfm today heaptrack, killed the process to let it complete the process, and here's the results to look for yourself. This doesn't look like much to me other than QImage* stuff seems the worst offenders, which might make sense as yesterday I was doing documentation for a project and taking a LOT of spectacle screen shots all night when it went from ~40 to ~90gig of memory used. Perhaps spectacle isn't playing nice, or at least it's graphic library isn't. I'll post a share to the heaptrack separately as it's large, but hopefully its helpful.
Created attachment 179152 [details] heaptrack of plasma @ 93gib used - topdown
Here's a google share to the heaptrack archive of the full monte. https://drive.google.com/file/d/1bpEUFGawZI24_6moVQuJ-549dvJ29Mr-/view?usp=sharing
Thanks for the details
Along with the host ram usage, I notice that kwin_wayland keeps using GPU memory as well, where right now it's using some 6.3GiB of vram per nvtop, which keeps steadily rising even after killing plasmashell to let it reclaim that ~90GiB of ram. Does it help to try to use heapstack to attach to it for a look at ram when we're talking gpu vram? How best to provide helpful data for something like this as well?
Just an update, this has been happening pretty much constantly, usually 1-2 days between needing to pop plasmashell manually to reclaim memory, or a few times oom kicked in, and this seems to occur independently of using spectacle or not. Anything else I can provide to help aside from the heaptrack?
FWIW, I made a false comment earlier that the bug has disappeared for me. It hasn't. I'm still observing the leak very frequently, watching `plasmashell` "RES" in top goes from 1G to >20G. One trick I found that can sometimes help reduce this number significantly: I have a dual monitor and disconnecting one of them sometimes greatly reduces RES (by a few GBs). But it doesn't save me from eventually having to logout.
Still the same issues here, now on 6.3.5 plasma as of Sunday, and if anything it's gotten worse that within 8 hours it'll use up whatever is left of 128gb of ram. I finally had to build a small systemd service to monitor and kill/restart plasmashell after it exceeds 20G of usage, but this is about every 2 hours, and during the work day quite annoying.
Ok, I seem to have fixed this now by disabling my Slideshow wallpapers on all of my displays. It was mentioned on the KDE forums it looked like libEGL and libEGL_nvidia were the root of the leak, but if the Slideshow is triggering it (some mention of external displays, which I have 2-3), then perhaps something with the compositor is causing it to freak out, and can be avoided in doing so as a quirk? I've not filed a bug report with nvidia yet still as their drivers have been in a constant state of f*ckery for the past few years already, but for me this has been happening at least since the 550 drivers when their adaptive sync stuff supposedly got fixed enough to actually use wayland, and now still on 575.57 as of Sunday. I'm also not entirely positive if this is more EGL/Mesa problem or Nvidia, thoughts who I should begin with? Hate to spam both and see who jumps first or annoy whoever isn't at fault. This seems to have stopped my gpu vram from climbing as well now, so a double win, as not only was it killing system memory, all 128gb, or whatever was left of it, within hours, but even just restarting plasmashell I'd get it and kwin_wayland creeping up gpu memory usage watching nvtop as well over days/weeks. Even under xorg I'd get vram leak to force a restart of my desktop to free it, even though not CPU memory leaking, now I'm curious if related. For now I suppose I'll live without wallpapers, but it would be nice to see this resolved, or at least avoided by nvidia fixes their drivers suitably. I can pull a new heaptrack if useful, otherwise here's my current versions of graphics things. $ pacman -Q | grep -E 'nvidia|plasma-desktop|egl|mesa|wayland' egl-gbm 1.1.2.1-1 egl-wayland 4:1.1.19-1 egl-x11 1.0.2-1 eglexternalplatform 1.2.1-1 kwayland 6.3.5-1 kwayland-integration 6.3.5-1 kwayland5 5.116.0-1 lib32-mesa 1:25.1.3-2 lib32-nvidia-utils 575.57.08-1 lib32-wayland 1.23.1-1 libnvidia-container 1.17.8-1 mesa 1:25.1.3-2 mesa-demos 9.0.0-6 mesa-utils 9.0.0-6 nvidia 575.57.08-2 nvidia-container-toolkit 1.17.8-1 nvidia-docker-compose 0.1.6-1 nvidia-settings 575.57.08-1 nvidia-utils 575.57.08-1 opencl-nvidia 575.57.08-1 plasma-desktop 6.3.5-1 plasma-wayland-protocols 1.18.0-1 qt5-wayland 5.15.17+kde+r57-1 qt6-wayland 6.9.1-1 wayland 1.23.1-2 wayland-protocols 1.44-1 wayland-utils 1.2.0-2 waylandpp 1.0.0-3 xorg-xwayland 24.1.6-1
(In reply to Michael Butash from comment #19) > It was mentioned on the KDE forums it looked like libEGL and libEGL_nvidia > were the root of the leak, but if the Slideshow is triggering it (some > mention of external displays, which I have 2-3), then perhaps something with > the compositor is causing it to freak out, and can be avoided in doing so as > a quirk? Actually one note on the slideshow wallpapers themselves that may be relevant... I have an entire directory I set for Slideshow of full 4K HD JPG files (~100) that I'm using here ranging from 8-25MB in size each (big for jpg's). I wonder if something is caching them (or stuck accidentally) in vram. They're all very busy artwork from digitalblasphemy.com, so who knows if just some weird errata tickling a hardware encoder in a way it doesn't like.
Sounds uncannily like the issue that Bug 480693 morphed into, which ended up being an NVIDIA driver issue. You seem like the kind of person who knows what he's doing, so please do feel free to report this issue to the NVIDIA developers, either by sending an email to linux-bugs@nvidia.com or making a post at https://forums.developer.nvidia.com/c/gpu-graphics/linux. It would be helpful to the them if you could run `nvidia-bug-report.sh` and attach the resulting file in your report. Thanks! *** This bug has been marked as a duplicate of bug 480693 ***
Confirmed that disabling slideshow fixed memleak for me. Thanks!