>Note: I was advised on that bug to open a new report.

Yes, thanks. 

I'm afraid I'm going to need a lot of info to narrow this down.

1) Does it mostly go away if you don't have a slideshow wallpaper?

2) Can I have the output of:
qdbus org.kde.KWin /KWin org.kde.KWin.supportInformation  

3) If you run "kcmshell5 qtquicksettings" does it go away if you set Render loop is set to "basic" and run "plasmashell --replace"



4) If you run "kcmshell5 qtquicksettings" does it go away if rendering backend is set to "software" and run "plasmashell --replace"

Created attachment 117657 [details]
kwin info

Unfortunately, it's going to be hard to answer "does it go away" questions, since it usually takes at least a few days before the issue becomes apparent. At best, I can try experiments and report back if some weeks pass without issue.

Kwin info is attached.

Okay... after initially making the first change (render loop = basic), it ran fine for a while, then X crashed. This morning, however:

  virt: 15.2G
  res:  11.8G
  shr:   3.8M
  mem:  37.6%
  time: 1h23m

Is it possible there is something different about the instance that's auto-started? I'm not entirely certain but what I may only be seeing problems with the initial auto-started instance...

...and again:
 v: 14.9G
 r: 13.0G
 m: 41%

This was with basic/software.

Information was provided with comment #2; changing status for inspection.

Can you attach your 

~/.config/plasmarc
~/.config/plasmashellrc
~/.config/plasma-org.kde.plasma.desktop-appletsrc

Created attachment 118227 [details]
plasmarc

Created attachment 118228 [details]
plasmashellrc

Created attachment 118229 [details]
plasma-org.kde.plasma.desktop-appletsrc

Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!

Requested information was provided AFAICT.

Hi. I see that there are many similar reports about Plasmashell Memory Leak problem occurring even to this day.
I don't use slideshow wallpaper. I never power off my PC, I always sleep/suspend to RAM. I can suspend to RAM and resume the PC several times without plasmashell memory leak problem happening, but suddenly sometime when I resume the PC the problem starts to occur and I can notice it when I resume from suspend to RAM and I get a little freeze in Plasma until it does it becomes responsive after a few seconds. So from this point I start to check Plasmashell RAM usage, and from this point the problem after suspending RAM and Resume is always reproducible. From this point every time you suspend to RAM and Resume, plasmashell increases RAM usage up to a lot and plasma becomes slower every time.
I'm not sure how to debug the problem when it occurs in order to provide some useful information.

Bump x5. 

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.

Soooo ... is this going to be fixed or does your users have to change to another DE?

I mean it's 3 years now and I still get memory leaks on a daily basis (with a sliding desktop wallpaper - not sure why this memory leak issue isn't fixed after 8 years...)

Will ever this bug will be fixed ? It is really annoying when you have to restart your computer several times a day because plasmashell has a huge memory leak... Isn't is possible to mark this bug as important, not as "normal" priority ? It litterally ruins the user experience.

I personnally don't use the slideshow background but I have these memory leaks anyways.

This is the issue that comes up when Googling "plasmashell memory leak", so I'll post here. There are usually multiple root causes of these types of problems, but without better ways to debug / investigate these issues than "try it with this configuration" it is really hard for users to determine whether we are talking about the same issue or not.

On my Fedora 36 system with 128 GB of real memory, systemd-oomd has killed plasmashell twice in two days for using almost 133 GB of memory (real memory + considerable swap). There is no conceivable situation in which plasmashell should be using that much memory.

Oct 23 03:04:40 edison systemd-oomd[1888]: Killed /user.slice/user-1000.slice/user@1000.service/session.slice/plasma-plasmashell.service due to memory used (132956889088) / total (134229807104) and swap used (27105050624) / total (30064758784) being more than 90.00%
Oct 23 03:04:40 edison systemd[2255]: plasma-plasmashell.service: systemd-oomd killed 199 process(es) in this unit.

and then almost exactly 24 hours later:

Oct 24 03:05:46 edison systemd-oomd[1888]: Killed /user.slice/user-1000.slice/user@1000.service/session.slice/plasma-plasmashell.service due to memory used (132685852672) / total (134229807104) and swap used (27061297152) / total (30064758784) being more than 90.00%
Oct 24 03:05:46 edison systemd[2255]: plasma-plasmashell.service: systemd-oomd killed 156 process(es) in this unit.

I do find it suspicious that both instances happened at almost exactly the same time overnight -- the cron log does not show any process triggering at or around that time.

If there is a way to effectively debug this sort of thing, that would be helpful.

I don't use slideshow wallpaper.

Output of qdbus supportInformation: https://invent.kde.org/-/snippets/2387

Created attachment 159213 [details]
Settings an KWin support info

For the past few weeks plasmashell (version plasma-workspace-x11-5.27.4.1-1.fc37.x86_64 from fedora RPMs) has been growing to tens of gigabytes while idle and getting killed by the oomkiller. I've attached my ~/config/plasma*rc and the kwin support info as requested above.

I've tried setting the Render loop to basic and will see if that changes anything.

Well that didn't help:

top - 00:29:30 up  8:52,  6 users,  load average: 3.24, 2.35, 2.20
Tasks: 412 total,   2 running, 410 sleeping,   0 stopped,   0 zombie
%Cpu(s):  1.9 us,  7.7 sy,  0.0 ni, 26.6 id, 63.3 wa,  0.3 hi,  0.3 si,  0.0 st
MiB Mem :  64229.3 total,    380.3 free,  63408.5 used,    440.5 buff/cache
MiB Swap:  69618.0 total,  22149.9 free,  47468.1 used.    141.8 avail Mem 

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND                                                                              
     76 root      20   0       0      0      0 R  38.5   0.0  22:44.61 kswapd0                                                                              
 114347 root      20   0   25.4g  39608  25700 S   7.6   0.1   1:32.63 Xorg                                                                                 
 114631 jwakely   20   0 1515740  20804  15968 S   2.7   0.0   0:04.83 kded5                                                                                
   3092 jwakely    9 -11  473512  12616   8144 S   2.3   0.0   0:02.24 wireplumber                                                                          
 114634 jwakely   20   0 1323284  53276  44564 D   2.3   0.1   1:02.43 kwin_x11                                                                             
 115789 jwakely   20   0 3071832  86556  30860 S   2.0   0.1   3:54.37 Isolated Web Co                                                                      
 115756 jwakely   20   0 3063488  87384  30896 S   1.7   0.1   3:52.92 Isolated Web Co                                                                      
 118895 jwakely   20   0  100.4g  54.9g  33756 D   1.7  87.5  30:56.40 plasmashell           


It's about 4 hours since I restarted plasmashell (then left the system idle), and it's reached 100gb and the system is performing badly due to swapping.

I'll try software rendering tomorrow.

> I'll try software rendering tomorrow.

That didn't make any difference. The last time I had the problem the plasmashell process grew to 78gb in about 20 minutes.

But I've noticed that when I turn off my display and watch plasmashell using `top` in an ssh session on another machine, it spikes to 100% CPU usage every 15-20 seconds. When the display is on, that doesn't happen, it stays at about 0% all the time. This observation seems correlated to the fact that the memory leaks happen when I'm away from the machine and it's idle, because I always turn the screen off when I leave the desk.

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND                                                                              
  22860 jwakely   20   0 2048664 399404 187656 S  96.3   0.6   0:32.10 QSGRenderThread                                                                      
   3222 jwakely   20   0 2048664 399404 187656 S   0.3   0.6   0:07.03 plasmashell                                                                          
   3238 jwakely   20   0 2048664 399404 187656 S   0.0   0.6   0:00.17 QDBusConnection                                                                      
   3239 jwakely   20   0 2048664 399404 187656 S   0.0   0.6   0:00.51 QXcbEventQueue                                                                       
   3352 jwakely   20   0 2048664 399404 187656 S   0.0   0.6   0:00.31 QQmlThread                                                                           
   3363 jwakely   20   0 2048664 399404 187656 S   0.0   0.6   0:00.31 Qt bearer threa                                                                      
   3508 jwakely   20   0 2048664 399404 187656 S   0.0   0.6   0:01.50 QQuickPixmapRea                                                                      
   3577 jwakely   20   0 2048664 399404 187656 S   0.0   0.6   0:00.00 CPMMListener                                                                         
   3588 jwakely   20   0 2048664 399404 187656 S   0.0   0.6   0:00.07 plasmashell                                                                          
   3728 jwakely   20   0 2048664 399404 187656 S   0.0   0.6   0:00.00 KCupsConnection                                                                      
   4218 jwakely   20   0 2048664 399404 187656 S   0.0   0.6   0:00.65 QSGRenderThread                                                                      
   8537 jwakely   20   0 2048664 399404 187656 S   0.0   0.6   0:00.34 QSGRenderThread                                                                      
  21405 jwakely   20   0 2048664 399404 187656 S   0.0   0.6   0:00.05 QSGRenderThread                                                                      
  21413 jwakely   20   0 2048664 399404 187656 S   0.0   0.6   0:00.38 QSGRenderThread     

That thread is running code from the nvidia drivers, so maybe that's where the problem is:

Thread 14 (Thread 0x7fdd7d5ba6c0 (LWP 22860) "QSGRenderThread"):
#0  0x00007fddcc52221f in __GI___poll (fds=0x7fdd7d5b95b8, nfds=1, timeout=1000) at ../sysdeps/unix/sysv/linux/poll.c:29
#1  0x00007fddb2912a50 in  () at /lib64/libnvidia-glcore.so.530.41.03
#2  0x00007fddb29c3e51 in  () at /lib64/libnvidia-glcore.so.530.41.03
#3  0x00007fddb9aefe1c in  () at /lib64/libGLX_nvidia.so.0
#4  0x00007fddb9abfe30 in  () at /lib64/libGLX_nvidia.so.0
#5  0x00007fddc874fe21 in QGLXContext::swapBuffers(QPlatformSurface*) (this=0x7fdd582c79d0, surface=0x55b4cb438680) at qglxintegration.cpp:637
#6  0x00007fddcea479db in QSGRenderThread::syncAndRender(QImage*) (this=this@entry=0x55b4cd1bc1c0, grabImage=grabImage@entry=0x0) at scenegraph/qsgthreadedrenderloop.cpp:869
#7  0x00007fddcea480eb in QSGRenderThread::run() (this=0x55b4cd1bc1c0) at scenegraph/qsgthreadedrenderloop.cpp:1042
#8  0x00007fddccae855b in operator() (__closure=<optimized out>) at thread/qthread_unix.cpp:350
#9  (anonymous namespace)::terminate_on_exception<QThreadPrivate::start(void*)::<lambda()> > (t=<optimized out>) at thread/qthread_unix.cpp:287
#10 QThreadPrivate::start(void*) (arg=0x55b4cd1bc1c0) at thread/qthread_unix.cpp:310
#11 0x00007fddcc4ae12d in start_thread (arg=<optimized out>) at pthread_create.c:442
#12 0x00007fddcc52fbc0 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

I don't know whether it's related, but Bug 465441 has heaptrack report attached with specific line number causing the leak.

(In reply to YAFU from comment #12)
> Hi. I see that there are many similar reports about Plasmashell Memory Leak
> problem occurring even to this day.
> I don't use slideshow wallpaper. I never power off my PC, I always
> sleep/suspend to RAM. I can suspend to RAM and resume the PC several times
> without plasmashell memory leak problem happening, but suddenly sometime
> when I resume the PC the problem starts to occur and I can notice it when I
> resume from suspend to RAM and I get a little freeze in Plasma until it does
> it becomes responsive after a few seconds. So from this point I start to
> check Plasmashell RAM usage, and from this point the problem after
> suspending RAM and Resume is always reproducible. From this point every time
> you suspend to RAM and Resume, plasmashell increases RAM usage up to a lot
> and plasma becomes slower every time.
> I'm not sure how to debug the problem when it occurs in order to provide
> some useful information.

I am having the exact same issue (2 years later...). The leak becomes apparent after about 20 sleep/resume cycles or so, then plasmashell memory consumption increases exponentially each time.

On Ubuntu Studio 22.04, KDE Plasma 5.24.7, X11 with NVidia RTX3060.

This bug still exists in plasma 6.0 (and current plasma 6.1 preview). I have observed this bug on both fedora and arch linux, going back at least 3 years. Interestingly I believe this bug is only affecting NVIDIA; I experience this memory leak with my RTX 4090 (and previous 3090) but not with an AMD 7900XTX. All three GPUs were tested with the same mobo/cpu/ram -- the CPU is an AMD 7800X3D. I have not tested if this leak occurs when using open source NVIDIA drivers, I have only used the proprietary drivers. However I believe it is a KDE bug and not an NVIDIA bug because I do not have similar memory leaks with GNOME or other wayland compositors (e.g. hyprland using swww wallpaper utility) regardless of GPU used.

I can confirm this bug for Intel, too.

Is anyone even interested in fixing bugs in KDE anymore? It's been 5 fucking years now.

Also, to the people looking at this and thinking "who cares, no one uses slideshow anyway", please consider the fact that OLED displays are rapidly becoming the standard display panel type on virtually all personal devices. Some sort of wallpaper slideshow or animated wallpaper is the most responsible way to use a wallpaper and minimize OLED burn-in over time. Until this bug is fixed I feel my only option is to use a pure black background. This is a pretty minor inconvenience but obviously quite annoying.

(In reply to Tyler Pennington from comment #25)
> Also, to the people looking at this and thinking "who cares, no one uses
> slideshow anyway", please consider the fact that OLED displays are rapidly
> becoming the standard display panel type on virtually all personal devices.
> Some sort of wallpaper slideshow or animated wallpaper is the most
> responsible way to use a wallpaper and minimize OLED burn-in over time.
> Until this bug is fixed I feel my only option is to use a pure black
> background. This is a pretty minor inconvenience but obviously quite
> annoying.

I don't think it's related to slideshow wallpapers. As others have noted, it even occurs with static wallpapers. I never used slideshows and I have the same issue. 

Since nothing seems to progress on this, I will simply go back to a stable desktop on the next opportunity.

I think I'm experiencing something similar with my Ryzen 3 4100 and AMD RX 6650XT, but with a static background, and instead of days, it is just a matter of hours

Still happening in 6.2.4, only happens when I'm using Wayland (using this because X11 session has random hard-freezes but that's another issue). 

Using almost 30% of my memory in 40 mins. 

What I need to trace to reveal what is causing the leak??

I'm also experiencing a memory leak that only happens on Wayland

I'd say plasmashells VRAM usage is a bit alarmig as well after just 2 days uptime, it uses 411Mb of VRAM. A freshly started plasmashell uses 158Mb VRAM on my system, so why does it keep increasing?
I don't see much increase in actual RAM usage tho'.

Nvidia added a workaround in their 565.77 driver for plasmashell so it should not be the driver that causes it.
I'm interested in knowing how plasmashells VRAM usage looks on AMD or intel after a few days?

Regarding VRAM, changing wallpapers makes the VRAM go up, change a few times, then change it back to the wallpaper you had originally, for me it went from 200Mb to 500Mb of VRAM.
This me trying to force it to happen but perhaps it can help you debug it.