major memory leak on plasmashell

Hi!
I have ArchLinux with Qt 5.4, KDE Framework 5.7.0 and KDE Plasma 5.2.0 installed on laptop.
During launch plasmashell uses almost twice more, than in KDE 4.14. During use plasmashell utilize over 600MB - that is more than as for KDE.
Install was made by different way:
- by deleting KDE 4.14 and then installing Plasma 5 with KDE Framework from official repository ArchLinux
- by installing clear ArchLinux and after that installing Plasma 5 with KDE Framework
- by installing clear ArchLinux and after that compiling Plasma 5 with KDE Framework from git sources

No one of this methods does not improve situation with using RAM on Plasma 5. In this form it is not suitable for use, even with 5.2.1 version released. In 4.14 plasma uses ~60mb ram on cold start, and not more than 80mb during use whole day. At case of 5.2.1 - 600mb by half day. This is more than all system and browser.
Hope, that this very big issue will be fixed with nearest releases.

Here is my explanation screenshots:
http://res.cloudinary.com/metsys/image/upload/v1425513469/kde5/image.png
http://res.cloudinary.com/metsys/image/upload/v1425513470/kde5/image1.png
http://res.cloudinary.com/metsys/image/upload/v1425513469/kde5/image2.png
http://res.cloudinary.com/metsys/image/upload/v1425513468/kde5/image3.png
http://rghost.net/private/8Qgfs2rd4/f05d5b1e87aad02d863e9009e864c8da]plasmashell.smaps

luebking advice me post this issue here, in bug tracker

here is my first post: https://forum.kde.org/viewtopic.php?f=289&t=125251

Reproducible: Always

Steps to Reproduce:
In dedails

Expected Results:
use max 100 mb ram ))

corrupted link, here is right:
http://rghost.net/private/8Qgfs2rd4/f05d5b1e87aad02d863e9009e864c8da

Welcome into JS world! :)

More plasma Debug http://rghost.net/private/8PVkCKVKd/6c607378e1060bcaf6f2935b287335cd

I see the same exact problem on my Gentoo 64bit laptop.
Plasma 5.2.1, KF5.7, Qt 5.4.1

Since I upgraded to plasma-5 I often run into an unresponsible (because of swapping) desktop, and have to hard-reset. Please have a look memory consumption please. I cannot upgrade my RAM anymore.

I'm affected to.

Which desktop applets are you using?
I'm not using any additional desktop applets, besides the following builtins:
- K-Menu
- Virtual Desktops Switcher
- Window switcher
- Clock

I've got what I assume to be the same problem. I upgraded to Kubuntu 15.04 with Plasma 5.2.
On boot plasmashell uses ~160MB ram. I left the machine idle with nothing but a Konsole running, and a few hours later plasmashell had 3.2GB res RAM.

Sadly I'm not sure what logs I should attach to let anyone make sense of this.

memsys, how did you create that valgrind output?

most importantly, how did you close valgrind/plasmashell.
Almost all these traces are just in Qt and it seems unlikely that's the problem.

can all of you above try removing applets to see if we can pinpoint one causing a problem.

Can you all above tell me what graphic card you're using + driver versions.

It happens on two different machines for me, one is an intel GM45 Express with a recent i915 driver

The only plasmoids I've got running in my tray are notifications, volume control, network, klipper and removable devices. I don't see any memory being freed up if I stop/remove any of them.

I'm using the nvidia 346.47 driver on a nvidia 770GTX card.

David Edmundson,
Here is info about graphic card and driver version:
http://res.cloudinary.com/metsys/image/upload/v1427053941/kde5/image.png

This is valgrind launch command:
localhost% valgrind --tool=memcheck --leak-check=full --leak-resolution=high --log-file=Plasma_Debug plasmashell and file created https://yadi.sk/d/pIXnTtd6fSbqB and https://yadi.sk/d/BiviLfVWfSbyd

"how did you close valgrind/plasmashell" - what do you mean? It's not clear for me, sorry for question.

All log files was created with default installed applets, if it matter, ok, I remove them and make new one test/log files.

Regards

Here is plasma launch without applets. After ~20 minutes closed by Ctrl+C https://yadi.sk/d/Szh6GAwTfSgqv
Here is valgrind results https://yadi.sk/d/WE0wP5xgfSgyS

https://yadi.sk/d/voVYIUg2fTRMH
- Plasma launch with 1 empty panel and 3 applets:
1. org.kde.plasma.kickoff
2. org.kde.plasma.systemtray (by adding this applet plasmashell crashed (KCrash: Application 'plasmashell' crashing...)
3. org.kde.plasma.taskmanager
After attempt to add third applet valgrind shutdown ([1] + exit 253 valgrind --tool=memcheck --leak-check=full --leak-resolution=high plasmashel)

and
https://yadi.sk/d/7jH9HwSBfTRi8 result of command:
valgrind --tool=memcheck --leak-check=full --leak-resolution=high --log-file=Plasma_Debug_3 plasmashell

It happens to me mostly some time after the screen was locked, but I can't confirm it is really related to each other.

*** Bug 345711 has been marked as a duplicate of this bug. ***

Have traced this down to the qt app: transmission-qt

The memory usage continuously rises while seeding with this app, after some time, possibly as much as an hour. Then immediately stops rising once I kill the app.

Transmission-gtk is fine.

This continues through the latest beta to 5.3.

Transmission-qt makes plasmashell use more memory?

Does it have a system tray icon? Does that icon do anything "odd"?

Ok David, that's it!

When I turn off the tray icon in transmission-qt (under preferences>desktop), the memory usage stops rising.

Good to know.

Sorry, didn't answer your question, David.

It is the plasmashell using the memory, and no, the icon was not doing anything odd, when on.

I have the same problem with plasmashell. I have no plasmoids on the desktop, and only a minimal menu bar.

My suspicion is that non-native apps are the issue. I use sparkleshare (a mono app), which I haven't managed to display in the system tray. Whenever it's running, plasmashell memory usage starts going up totally out of control.

I experience the same problems on plasma 5.3 with no plasmoids, but with owncloud sync client running. I notice the problem only after I unlock the lock screen, and in my case Xorg.bin does exactly the same thing. Whereas "plasmashell" uses up to 2GB of Ram, Xorg.bin doubles the ram usage. I have attached smaps and screenshots from ksysguard.

Created attachment 92365
Plasma memory usage smap export

Created attachment 92366
ksysguard detailed view of plasmashell memory usage

Created attachment 92367
ksysguard view of plasmashell and xorg memory usage

I forgot to add that I am using Fedora packages:
Fedora 21
Linux 3.19.5-200.fc21
KDE Plasma 5.3

Also I do not have transmission-qt or transmission installed or running

bugzy, can you list what things you do have in the sysem tray?

@ David Edmundson
On Desktop: I have owncloud-client 1.8.0 in the system tray
On Laptop: I have owncloud-client 1.8.0 and qsynergy 0.9.1 in the system tray

I am experimenting with turning off both applications later today to see if I can still reproduce the problem. I will let you know the results.

Created attachment 92380
System Tray Items

It just occured to me that you asked me to list all items so here is a screenshot of my system tray

I pushed a few things in frameworks 5.11, I doubt they'll make a huge difference.
Also some leaks in libdbusmenu-qt which are pending merge.

I'll leave this open till I'm able to run the system tray under valgrind properly

@ David Edmundson
Thanks.
Also, I was able to run a few "layman" tests, and can confirm that when I have neither owncloud client nor qsynergy in the tray, the memory usage stays sane.

I installed Fedora 22 on a virtualbox without 3d acceleration.
I am experimenting huge processor load under kde -> plasmashell using 120% of processor on 2 procs.
After trying a little bit, I was able to get the processor load back to normal by removing all plasma widgets on my desktop.
Once I add a plasma widget, the processor load rise to 120 % (tested with just an analog clock, just a notes, and just a processor load watch).

The version of kde installed under Fedora 22 is kf5 - 5.10.0

Same problem here.
Plasma 5.3.1
ArchLinux
Intel video.

I performed some tests.
If I have just a notes and a clock plasma widget, there is no cpu overload.
If I put a cpu load monitor and / or a memory monitor plasma widget, then the cpu load rise to 120 %.

Same issue here. After around 3h I have 2gb ram usage from plasmashell. I am not sure if this is an interaction with another program: I only noticed this issue after playing dota 2 for some time and the pc got barely responsible. Looking into ksysmon I saw that plasmashell uses a lot of ram. After killing it and restarting it, everything went back to normal.

Is this an interaction of programs that use plasmas notify system?

Downgraded kdebase-plasma to 15.04.1-1, didn't help too much (1.8Gb ram by plasma-desktop process while played wine game couple hrs)
Next downagraded qt4 to 4.8.6-6 ... leak is slowed.

Latest updates leaks simply by clicking button of konsole window on panel - each minimize leaks about 3kb, restore 1kb around...

with those 2 downgrades it is very slowed down as far as I see, now it hundreds of bytes of changes (instead kilobytes).

yeh.. 30-40 minutes of doing the same - konsole/chrome/pidgin .... still 104Mb (instead 800mb this morning).

So qt 4.8.7-1 makes plasma to leak and 4.8.6-6 not.

I am seeing a lot those:
 New Notification: "Kopete Messenger" "<html><i>someone someone</i> is now Online.</html>" -1 & Part of: 0
file:///usr/lib/qt/qml/QtQuick/Controls/Button.qml:100: TypeError: Cannot read property of null
trying to show an empty dialog
Currrent active notifications: QHash()
Guessing partOf as: 0
 New Notification: "Kopete Messenger" "<html><i>someone someone</i> is now Online.</html>" -1 & Part of: 0
file:///usr/lib/qt/qml/QtQuick/Controls/Button.qml:100: TypeError: Cannot read property of null
trying to show an empty dialog

And memory increases by ~1MB every notification.

I later also tested transmission-Qt5. It was making plasmashell use 1MB more memory per second or two.

Created attachment 93146
Every time crash on ram usage around 300M

Ram usage around click on clipboard or other in system tray. kf5.11 plasma 5.3.1

@ycollet
I believe that the problem that you have described is different from the one being discussed here. I think it will be good to create a separate bug report for the cpu load issue. Nevertheless, I have experienced the CPU rise issue in similar circumstances. It seems that whenever you put a frequently updated plasmoid either in the system tray or on the desktop, the cpu spikes.
In my case, whenever my plasma-nm or the notification icon are showing the spinner (the semi-circular stuff that spins around the a pertinent icon in the system tray to indicate that work is being done) for loading a connection or displaying the status of a copy job that takes a while to complete, my CPU usage goes wild, and I know that it is not caused by the connection or the copy job (i.e. the same copy on cli shows no issues.)

Okay so the point of this comment was to move the CPU issue into another bug :). Sorry to divert from the discussion of this memory leak problem.

@ycollet
For CPU load rise issue see:
https://bugs.kde.org/show_bug.cgi?id=345141
https://bugs.kde.org/show_bug.cgi?id=348385
https://bugs.kde.org/show_bug.cgi?id=346668

Hello.

I am having same problem on my desktop: plasmashell eats as much memory as is can. I have even spotted 2g consumed in RES column of top.

After reading this bugreport I disabled tray icon for my Psi+ (it uses animated icons) and memory consumption has gone. I can't say that having no icon for IM is very convenient, but at least I don't need to restart plasmashell every day.

So I think this info may be helpful:
• there was an animated tray icon from third-party Qt-4 application (Qt 4.8.6)
• it was definetely "animating" while my session was locked, usually it was blinkig for the whole night
• i am not using any screensavers, just lock screen.
• I had to remove the animated tray icon to eliminate memory consumption
• there is one more tray icon from some KDE application (it says I have updates for my system) which is not animated and seems not to affect plasmashell's memory consumption.

Thank you.

Created attachment 93253
With Qt 5.4.2 debug symbols

Same issue on Manjaro Plasma 5.3.1, KF5.11

I found one issue which causes memory increasement:
When I click to the panel to add widgets, plasmashell CPU usage became about 10% from zero and memory increases continuously (about 30 MB in a minute).

Even if there is no change on the panel the memory increasement does not disapear.

Other programs may increase plasmashell as well as after a few hours plasmashell memory takes about 600MB instead of the starting 200MB.

But for one issue, there is the add widgets function in the panel which creates huge memory usage.

Since this is likely because of the use of JS, any way to implement garbage collecting?

I can confirm the huge RAM usage in (K)ubuntu 15.04, after updating from 14.10.

I was using two panels (one bottom, one top) in the first screen of a dual screen setup. I had some application icons, show desktop, trash icon, the systray and the clock in the top panel and the taskbar in the bottom one. Backgrounds set to black color in both screens. Systray elements: kmix, networkmanager, klipper, notifications and updates. No desktop widgets.

I can't give more info because after finding KDE was using 2,7GB of my 4GB RAM I immediatelly went back to the 14.10 installation backup so I could start working. Not updating until Javascript is grounded I guess.

Arch linux
extra/plasma-workspace 5.3.1-1 (plasma)

Memory usage of plasmashell climbs drastically (in like 30mins, not sure yet if this related to background kio_ssh file copy), desktop becomes choppy, when mem usage reaches 6.6GiB (sic!) it crashes.

I am also seeing this problem in the KDE spin of Fedora 22 (plasma-workspace.x86_64, v5.3.1-2). After using the system for a while (not sure on the amount of time), RAM usage is around 3-4 gigs with just the desktop and Konsole running.

Not sure if this is the same issue, but when the memory usage is high the desktop starts flickering when I select applications from the taskbar, and windows aren't rendered completely/correctly.

>Also, I was able to run a few "layman" tests, and can confirm that when I have neither owncloud client nor qsynergy in the tray, the memory usage stays sane.

I think we can be pretty sure it happens with certain system tray icons.

qbittorrent spits out TootltipChanged signals once a second, the others probably do the same. Which means if there is even a tiny leak updating SNIs, it will fill up pretty quickly.

Though, I still can't reproduce locally, and valgrind showed everything being fine.

There was a fix in Qt > 5.4.1 to some QtDBus memory allocation.

Can someone confirm they still have it with that version of Qt?

Can people start a list of what apps trigger this, maybe we can find a useful pattern.

Finally, could someone with a leak capture the dbus traffic on their system whilst the memory is increasing.
ideally with bustle, or worst case dbus-monitor. Note these may contain personal information from whatever else is running, so be careful before sending.

(In reply to David Edmundson from comment #50)
About me, widgets has a leaks, media player, weather and ones with timers, they fast increase RAM usage.

Could you be a lot more specific.
Obviously adding more things is going to increase the usage

What I'm concerned about are where we add something and that starts a continued rise of usage when left idle.

Have you tried this one?

"When I click to the panel to add widgets, plasmashell CPU usage became about 10% from zero and memory increases continuously (about 30 MB in a minute). Even if there is no change on the panel the memory increasement does not disapear."

Yes.

(In reply to David Edmundson from comment #50)
> >Also, I was able to run a few "layman" tests, and can confirm that when I have neither owncloud client nor qsynergy in the tray, the memory usage stays sane.
>
> I think we can be pretty sure it happens with certain system tray icons.
>
> qbittorrent spits out TootltipChanged signals once a second, the others
> probably do the same. Which means if there is even a tiny leak updating
> SNIs, it will fill up pretty quickly.
>
> Though, I still can't reproduce locally, and valgrind showed everything
> being fine.
>
> There was a fix in Qt > 5.4.1 to some QtDBus memory allocation.
>
> Can someone confirm they still have it with that version of Qt?
>
> Can people start a list of what apps trigger this, maybe we can find a
> useful pattern.
>
> Finally, could someone with a leak capture the dbus traffic on their system
> whilst the memory is increasing.
> ideally with bustle, or worst case dbus-monitor. Note these may contain
> personal information from whatever else is running, so be careful before
> sending.

David, transmission-qt on Arch Linux with all latest plasma and Qt-5.4.2, is still increasing RAM as before, as I enable Prefs>Desktop>"Show Transmission icon in the notification area". Disabling it stops it.

Have not tried bustle, however notice that it is in the AUR. Please post how to use and grab what/where the information you need.

Thanks

(In reply to David Edmundson from comment #52)
Look RAM usage then start player with mpris2 (dragon, juk, etc) media player is loading, RAM will increasly by every stop -> start player.

I just add zram to the system like this https://wiki.debian.org/ZRam and now I see no any "memory leak" at all, not by plasmashell, not by iceweasel (firefox) and so on and no any freezing. I guess all problems goes from memory cache and swap.

Not sure :/ Something changed in Qt. Frozen 4.8.6 just works, had 32-bit of 4.8.7 yet - Skype failed to start, had to rollback it too.

I can notice, after 7 days of usage nor restart nor logout with kf 5.12 since tagged, nor high ram, nor cpu usage nor radomply crashes. Can anyone confirm?

Yes, RAM usage doesn't increase anymore for me. Would be interesting what the cause was

For me this is also solved now

With Kf5.13 and plasma 5.4 the problem seems to have returned for me. plasmashell is currently using 2.4G.

Have that problem been backported to KDE4? The plasma-desktop process begin leaking for about 1MB per 1-2 seconds when I start transmission-qt in my Archlinux with KDE4 (kdebase-workspace 4.11.22-2). Just like described above.

I have the same problem with 5.14 and Qt 5.5 on two systems.

Transmission-Qt must be doing something weird.
There are obviously some memory leaks in plasmashell but the transmission issue is one of the notable ones.
Perhaps someone should be contacting the transmission Qt frontend maintainer.
His name is "Jordan Lee" according to the https://trac.transmissionbt.com/browser/trunk/AUTHORS
(An email is in the Authors file as well)

Hi

i think, my problem is more related to this bug https://bugs.kde.org/show_bug.cgi?id=352854
But will observe both bugs

I'm seeing a slow but steady increase in Plasma memory usage which means I have to reboot my system at least once a day.

I see others are also pinning this on notification tray updates. The memory leak only seems to happen when I'm running the ownCloud client, which has an entry in the "Status & Notifications" area. Sounds like this happens whenever an application updates its notification area, since my memory leak is quite slow, but Transmission which updates far more frequently than ownCloud client apparently suffers much worse. (I don't know, I don't have Transmission installed)

Please let me know if there are any further details or tests that may help :)

Running Manjaro (ie. Arch, more or less) with Plasma 5.4.2, Qt 5.5.0, Frameworks 5.15.0, Apps 15.08.2.

Thanks :)

(In reply to Dan Mac from comment #67)
> I'm seeing a slow but steady increase in Plasma memory usage which means I
> have to reboot my system at least once a day.
>
> I see others are also pinning this on notification tray updates. The memory
> leak only seems to happen when I'm running the ownCloud client, which has an
> entry in the "Status & Notifications" area. Sounds like this happens
> whenever an application updates its notification area, since my memory leak
> is quite slow, but Transmission which updates far more frequently than
> ownCloud client apparently suffers much worse. (I don't know, I don't have
> Transmission installed)
>
> Please let me know if there are any further details or tests that may help :)
>
> Running Manjaro (ie. Arch, more or less) with Plasma 5.4.2, Qt 5.5.0,
> Frameworks 5.15.0, Apps 15.08.2.
>
> Thanks :)

You can simply restart plasmashell (kquitapp5 plasmashell && sleep 5 && plasmashell & disown). logging off/logging back in also restarts Xorg process in case it is eating up memory as well. You don't have to reboot your machine.

Hello,

Any progress on this?

I just installed openSUSE Leap 42.1 and am also suffering from this issue. I have to kill and restart plasmashell every day while looking at how much it consumes memory.

ok.. i will NOT unfreeze 4.8.6 KDE yet i did and it goes...on arch

(In reply to alexzkhr from comment #71)
> ok.. i will NOT unfreeze 4.8.6 KDE yet i did and it goes...on arch

QT i meant :D 4.8.6

I have a strong suspicion that the leak is in the network component of the shell. Whenever I add a networking monitoring widget, memory consumption increases each time that widget refreshes its info. I tried two different network monitoring widgets and I get the same behavior.

If I remove them, then memory consumption remains more or less steady, only at times very slightly increasing. I cannot fully blame the network component as memory still increases, but very very slightly

This is on a openSUSE Leap 42.1 install with Qt 5.5.0 and latest stable KF5

Created attachment 95400
valgrind with memory leak

I hit the same problem with RAM usage.
I don't have any special widgets (only Yahoo Weather Widget) or icon's in tray.

This looks pretty similar to https://bugs.kde.org/show_bug.cgi?id=314919

Is it possible that the same problem exists in plasma 5 while it got fixed in plasma4?

Is there any hope that any plasma developer installs Psi and traces the bug?

I've this bug, too. By ksysquard's data, plasmashell starts from ~90M RAM usage and growing it up continiously. It can eat approximately 100-200M per hour, even without any user activity. After running in console 'kquitapp5 plasmashell && sleep 5 && plasmashell & disown', memory usage is restored to ~90M and still growing again. I've not installed any third-party widgets or some manually builded packages. Turning effects off and|or widgets removing doesn't help.

Configuration info: Arch Linux 64-bit distribution with latest updates, AMD Phenom 810x4 CPU, GF 9800GT video with Nouveau drivers & Mesa installed, GB MA790X-DS4 motherboard, 8GB RAM, Plantronics wireless audio, wired network driven by Network Manager.

(In reply to Dmitry from comment #76)
> I've this bug, too. By ksysquard's data, plasmashell starts from ~90M RAM
> usage and growing it up continiously. It can eat approximately 100-200M per
> hour, even without any user activity. After running in console 'kquitapp5
> plasmashell && sleep 5 && plasmashell & disown', memory usage is restored to
> ~90M and still growing again. I've not installed any third-party widgets or
> some manually builded packages. Turning effects off and|or widgets removing
> doesn't help.
>
> Configuration info: Arch Linux 64-bit distribution with latest updates, AMD
> Phenom 810x4 CPU, GF 9800GT video with Nouveau drivers & Mesa installed, GB
> MA790X-DS4 motherboard, 8GB RAM, Plantronics wireless audio, wired network
> driven by Network Manager.

I have almost the same situation except that htop and ksysguard shows that plasmashell only uses (~80MB-90MB) but my whole system is out of free memory.

After plasmashell restart and type "echo 1 > /proc/sys/vm/drop_caches" everything back's to normal.
This happen on my laptop (Intel graphics) and older second PC-box (Radeon card).

After some debugging I ran plasmashell with GALLIUM_HUD="requested-VRAM,requested-GTT,VRAM-usage,GTT-usage" and noticed strange thing.
VRAM goes to max, then GTT goes to max. After VRAM and GTT is full then htop and ksysguard show that something start eating my free memory. I'm not sure if this is possible but it looks like if VRAM and GTT is full then mesa/driver/etc is trying to use system memory. The eaisiest way to reproduce this is hovering over taskbar and desktop items.

I know nothing about OpenGL but I can imagine that textures are not removed and we have memory leak :)

Dmitry can you run plasmashell with GALLIUM_HUD (if you are using noveau mesa driver) and see if you will have similar effects ? :)

A comment in a Plasma 4 bug update today is very interesting.

>Was fixed for me by installing the 'freetype2' instead of the 'freetype2-infinality-git', installed earlier. >Looks like this was memory leak in the 'freetype2-infinality-git'.

*if* that's the culprit, it's going to cross over into being this.

(https://bugs.kde.org/show_bug.cgi?id=342374#c51)

Could you guys see if it makes a difference.

@David Edmunson

I don't have that freetype2 pkg installed on my system, but memory still rises

freetype2 without infinality didn't help.

But I recompiled qt and plasma5 without gles2 support (Gentoo USE="-gles2 -gles") and now everything looks correct and even better (apps uses less memory and everything is smoother).

Getting this issue in Arch Linux testing with plasma 5.5. Just had to close all my apps and restart desktop, because Xorg was at 2.7G RAM usage. Xorg is the main issue, as it's memory usage raises faster than that of plasma. Plasma 5.4 didn't show this problem. 5.4.95 did, and issue is still present in 5.5 final.

(In reply to André Vitor de Lima Matos from comment #81)
> Getting this issue in Arch Linux testing with plasma 5.5. Just had to close
> all my apps and restart desktop, because Xorg was at 2.7G RAM usage. Xorg is
> the main issue, as it's memory usage raises faster than that of plasma.
> Plasma 5.4 didn't show this problem. 5.4.95 did, and issue is still present
> in 5.5 final.

Did you happen to suspend or hibernate during the session where Xorg reached 2.7G RAM?

(In reply to Hussam Al-Tayeb from comment #82)
> Did you happen to suspend or hibernate during the session where Xorg reached
> 2.7G RAM?

Yes. I suspend my system often (at least once a day).

(In reply to André Vitor de Lima Matos from comment #83)
> (In reply to Hussam Al-Tayeb from comment #82)
> > Did you happen to suspend or hibernate during the session where Xorg reached
> > 2.7G RAM?
>
> Yes. I suspend my system often (at least once a day).

But exactly now, my Xorg is at 1G ram, and increasing, plasmashell 151M (ok). I have not suspended this session, rebooted computer by the morning (kernel 4.3.1 update).

Provide output of xrestop.

Created attachment 95993
xrestop

xrestop output, with Xorg at 655M res memory usage. Not too helpful, I think, as look like a lot of memory is "missing", suggesting a memory leak inside X.

I have the same issue, Arch Linux and Plasma 5.5. Xorg is currently using 1,2 GB of memory. Plasmashell 196M. It happened yesterday as well.
I'm not using infinality. I don't use suspend or hibernate.

Anyone knows which packages and options to recompile in ArchLinux to remove OpenGL2 ES from plasma/kwin, so I could test if it's the problem's source?

Created attachment 96025
xrestop of valgrind session

Ran Xorg with debug symbols (in Xorg server and Intel driver). Finished session with Xorg (and valgrind) taking around 830M RES mem, 1120M VIRT mem.
Looks like creating windows increase memory usage. Closing windows free some resources, but not everything.

Created attachment 96026
Xorg's pmap of previous session, without valgrind, around 1.3G

This pmap dump is from a previous session, without valgrind or debug symbols in Xorg, that took around 1.3G RAM. Notice in the begining of the file, [anon] memory address taking almost all 1.3G RAM (memory leak)

Created attachment 96027
Xorg's pmap of valgrind+debug symbols session

In this one, memory usage looks more scattered than without valgrind or debug symbols. Still, finished it with 830M+ RAM usage by xorg.

Created attachment 96028
valgrind log of Xorg with debug symbols, from start to end

Xorg's valgrind run, with debug symbols, through shell script with following command line:
exec valgrind --error-limit=no --leak-check=full --log-file=/tmp/Xorg-valgrind.log /usr/lib/xorg-server/Xorg.valgrind "$@"
Finished with 830M+ RAM usage, even with no windows open.

Experiencing this as well for quite some time now. Went up to 2gb within 4 hours, 4gb within 8 hours. Pretty linear.

It's always happening, having a pretty fresh kubuntu 15.10 install (with updates). I can reproduce it by being afk, so let me know if I can do anything to get this backtraced.

I have got - not scientific :) - feeling the leak is correlated with workspace background: using solid color helps.

Interestingly, for me, extremely reproducable if I'm running Wine OpenGL applications. There I've like 1mb/s mem leak. Running no wine OpenGL application, it seems to be pretty stable.

But why would plasmashell freak out because of wine OpenGL applications?

Fact is, as soon as I start an OpenGL application in Wine (as WoW), plasmashell it leask 920k/s. As soon as I close it, it stops leaking. Note that normal Wine applications don't start the leak, as in example the Battle.net Launcher.

So that seems to be connected at least.

I have an idea but it is difficult to explain. Picture a compositor written in Qt5 and using opengl. Applications using libx11 directly and not Qt5 are causing leaks.

Decided to put some time on this issue tonight. Happens on the following distributions:
Arch, KUbuntu, OpenSUSE, Fedora (KDE Build), Tanglu (3.0, 4.0 Alpha), Manjaro, Mint

Happens on DEs: Only KDE. DEs Tested:
KDE, Unity, Gnome, LXQt, KDE, LXDE, Cinnamon, MATE, Xfce.

I think the leak only happens when I play CS GO (OpenGL app) and plasmashell is running. I now stop the plasmashell process while playing, and Xorg seems to have a normal memory usage.

I think so too. Especially if wine was leaking in libx11, we'd see a different pattern (other DEs would very likely leak too!).

I didn't experience this on native OpenGL applications (yet) though, but I'l do some checks on that as well the next few days.

(In reply to AnAkkk from comment #98)
> I think the leak only happens when I play CS GO (OpenGL app)...

I guess this generalization is too wide: I don't play games at all, but the leak takes place.

(In reply to Andrew Gaydenko from comment #100)
> (In reply to AnAkkk from comment #98)
> > I think the leak only happens when I play CS GO (OpenGL app)...
>
> I guess this generalization is too wide: I don't play games at all, but the
> leak takes place.

Perhaps everything not gtk3/Qt5/sdl2 is causing leaks?

Anyone on NVIDIA proprietary driver and getting memory leaks in Xorg process, can you try the following?
1) swapoff -a
2) quit all applications and anything minimized to your system tray but keep a terminal open and restart kwin (kwin_x11 or something --replace & disown).
3) close your terminal application.
4) Then ctrl+alt+F3 or F4 then ctrl+alt+f1 back to your session.
5) swapon -a
6) Check if Xorg process is now using less memory (in other terms, if some garbage collection happened).

I am having the same problem as André Vitor de Lima Matos. Here's what I know:

* Only killing the X server reclaims the memory (killing plasmashell/kwin_x11 doesn't release it); it leaks about 5GB per day
* Plasma/kwin 5.5.2 (has been occurring for a while though)
* EGL/OpenGL 2.0 are my compositing options, but it happens with xrender too
* Using Intel driver 2.99.917-r2, Xorg 1.17.4, Kernel 4.3.3
* No real widgets besides the default
* I run thunderbird from time to time (but leaks even when I don't run it), firefox (5 or so tabs, no inordinate memory usage), pidgin (a few conversations), konversation (about 35 tabs or so), and konsole (pretty much vim, htop, and basic system administration tasks).
* plasmashell is using about 200M of memory, kwin_x11 is using about 40M of memory
* xrestop shows nothing out of the ordinary
* Suspending does not worsen it (I don't hibernate)
* I run infinality
* I have only one tray icon not from KDE: pidgin, and it blinking doesn't seem to worsen the problem after a cursory look
* Closing/opening windows doesn't seem to cause it (though it changes memory usage slightly, it doesn't resolve the general leak)
* Rolling over the task manager (looking at thumbnails) doesn't cause it

I'm at a loss as to what more I can do, though, to elucidate the bug. It seems to happen under ill-defined circumstances.

(In reply to Elizabeth Myers from comment #103)
> I am having the same problem as André Vitor de Lima Matos. Here's what I
> know:
>
> * Only killing the X server reclaims the memory (killing
> plasmashell/kwin_x11 doesn't release it); it leaks about 5GB per day
Can you try my suggestion please? close all applications including system tray ones after disabling swap. restart kwin_x11/plasma and ctrl+alt+f3 or f4 and then ctrl+alt+f1 back to your X session.
I would like to know if ctrl+alt+f* operations are triggering garbage collection in Xorg.

> * I run infinality
I think infinality patches can cause issues

(In reply to Hussam Al-Tayeb from comment #104)
> Can you try my suggestion please? close all applications including system
> tray ones after disabling swap. restart kwin_x11/plasma and ctrl+alt+f3 or
> f4 and then ctrl+alt+f1 back to your X session.

I usually don't have swap enabled. The memory usage goes down when I close the apps and switch to a TTY to kill plasma and kwin_x11 (more from closing apps than anything else) but the leaked memory seems to remain.

Note though I only tried this when X was using about 300MB of memory (it starts with about 100). I will try it when the memory usage goes up again to the gigabyte range.

> I think infinality patches can cause issues

I've never had issues with them. I can try switching, but call me skeptical.

(In reply to Elizabeth Myers from comment #105)
> I usually don't have swap enabled. The memory usage goes down when I close
> the apps and switch to a TTY to kill plasma and kwin_x11 (more from closing
> apps than anything else) but the leaked memory seems to remain.
Thank you. That is what I was trying to figure out.
If I understand correctly, closing an application and then switching to a TTY and back causes Xorg to release the xserver memory used for that application. If memory leaks remain afterwards, then this indicates issues with the xorg driver and the compositor (kwin_x11 in your case).

I never had swap enabled, and didn't use infinality either. For some reason I haven't had the issue the last few days though, it looks like it fixed itself for me. I have no idea what changed, maybe this is after I updated to Plasma 5.5.2.

Confirming that at least main memory leak is gone in plasma 5.5.2. Creating and closing lots of windows (which triggered leak previously) doesn't seem to leak anymore, as Xorg recovers memory after that windows were closed.

I've tried another compositing WM (xfwm4) and I have no leaks. It definitely seems to be something KDE is doing.

problem still exists on a version 5.5.3
apparently any plasmoid refresh take next leak
just set the display seconds in clock and during the day plasmashell take 600 mB ram

That test case is not reproducible for me, clock widget with seconds displayed... plasmashell hasn't grown any over the course of the past few minutes at least.

(In reply to painless roaster from comment #110)
Did you use Breeze? https://bugs.kde.org/show_bug.cgi?id=357800
Select Oxygen LookAndFeeel, logout - login make same tests.

(In reply to Rex Dieter from comment #111)
> That test case is not reproducible for me, clock widget with seconds
> displayed... plasmashell hasn't grown any over the course of the past few
> minutes at least.

Few minutes is very short time for test with clock.

Faster test:
 - download plasmoid thermal monitor and set:
     - refresh speed - 0.1s
     - create 5 fields for temperature monitoring (physical id and 4 cores)
 - in this test is leak speed is 12MB / minute

Is any chance for use memory leak profiler please? For example compile plasma-workspace with library jemalloc and use jeprof.
Valgrind is too slow and not monitor during run. But jemalloc is ideal library for memory monitoring.

(In reply to Rex Dieter from comment #111)
> That test case is not reproducible for me, clock widget with seconds
> displayed... plasmashell hasn't grown any over the course of the past few
> minutes at least.

I tried leak with thermal monitor on second pc. Leak exists, but it is slower (500kB / minute) . But for leak need set 6 virtual workspaces.

(In reply to Anthony from comment #112)
> (In reply to painless roaster from comment #110)
> Did you use Breeze? https://bugs.kde.org/show_bug.cgi?id=357800
> Select Oxygen LookAndFeeel, logout - login make same tests.

Leak (new test with thermal monitor) exists with oxygen and breeze .

I find that the leak persists even when the screensaver kicks in (overnight), so I wake to "kquitapp5 plasmashell && sleep 10s && plasmashell &>/dev/null & disown" every day.
I have a handful of systray icons which are handled by the xembed-sni-proxy, and I wonder if that contributes.
Also, if I let plasmashell's stdout and stderr come to my terminal window, I see xcb errors every time i move my mouse pointer over the taskbar and hover from one window marker to the next.
I don't know if either of these facts are helpful.

(In reply to painless roaster from comment #113)
> Faster test:
> - download plasmoid thermal monitor and set:
> - refresh speed - 0.1s
> - create 5 fields for temperature monitoring (physical id and 4 cores)
> - in this test is leak speed is 12MB / minute
>
> Is any chance for use memory leak profiler please? For example compile
> plasma-workspace with library jemalloc and use jeprof.
> Valgrind is too slow and not monitor during run. But jemalloc is ideal
> library for memory monitoring.

I cannot confirm i use it regular since it created, not remember, not leak at all. Tell your graphic driver, mine is radeon, your nvidia?

(In reply to Anthony from comment #117)
> (In reply to painless roaster from comment #113)
> > Faster test:
> > - download plasmoid thermal monitor and set:
> > - refresh speed - 0.1s
> > - create 5 fields for temperature monitoring (physical id and 4 cores)
> > - in this test is leak speed is 12MB / minute
> >
> > Is any chance for use memory leak profiler please? For example compile
> > plasma-workspace with library jemalloc and use jeprof.
> > Valgrind is too slow and not monitor during run. But jemalloc is ideal
> > library for memory monitoring.
>
> I cannot confirm i use it regular since it created, not remember, not leak
> at all. Tell your graphic driver, mine is radeon, your nvidia?

nouveau 1.0.12

$ uname -a
Linux 4.3.3-303.fc23.x86_64 #1 SMP Tue Jan 19 18:31:55 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

$ lspci | grep VGA
01:00.0 VGA compatible controller: NVIDIA Corporation GT216 [GeForce 210] (rev a2)

$ rpm -q xorg-x11-drv-nouveau
xorg-x11-drv-nouveau-1.0.12-1.fc23.x86_64

valgrind detect memor leak (from 15minutes run) here:

==13702== 56,137,960 bytes in 32,858 blocks are definitely lost in loss record 62,663 of 62,663
==13702== at 0x4C28C50: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==13702== by 0x7496DFA: QSGBatchRenderer::Renderer::map(QSGBatchRenderer::Buffer*, int, bool) (in /usr/lib64/libQt5Quick.so.5.5.1)
==13702== by 0x7499074: QSGBatchRenderer::Renderer::uploadBatch(QSGBatchRenderer::Batch*) (in /usr/lib64/libQt5Quick.so.5.5.1)
==13702== by 0x74A4375: QSGBatchRenderer::Renderer::render() (in /usr/lib64/libQt5Quick.so.5.5.1)
==13702== by 0x74B00AE: QSGRenderer::renderScene(QSGBindable const&) (in /usr/lib64/libQt5Quick.so.5.5.1)
==13702== by 0x74B08FA: QSGRenderer::renderScene(unsigned int) (in /usr/lib64/libQt5Quick.so.5.5.1)
==13702== by 0x74C0DDD: QSGRenderContext::renderNextFrame(QSGRenderer*, unsigned int) (in /usr/lib64/libQt5Quick.so.5.5.1)
==13702== by 0x750ADCA: QQuickWindowPrivate::renderSceneGraph(QSize const&) (in /usr/lib64/libQt5Quick.so.5.5.1)
==13702== by 0x74DB78A: ??? (in /usr/lib64/libQt5Quick.so.5.5.1)
==13702== by 0x74DC890: ??? (in /usr/lib64/libQt5Quick.so.5.5.1)
==13702== by 0xA9D041B: QApplicationPrivate::notify_helper(QObject*, QEvent*) (in /usr/lib64/libQt5Widgets.so.5.5.1)
==13702== by 0xA9D58E5: QApplication::notify(QObject*, QEvent*) (in /usr/lib64/libQt5Widgets.so.5.5.1)

(In reply to painless roaster from comment #119)
> valgrind detect memor leak (from 15minutes run) here:
>
> ==13702== 56,137,960 bytes in 32,858 blocks are definitely lost in loss
> record 62,663 of 62,663
> ==13702== at 0x4C28C50: malloc (in
> /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==13702== by 0x7496DFA:
> QSGBatchRenderer::Renderer::map(QSGBatchRenderer::Buffer*, int, bool) (in
> /usr/lib64/libQt5Quick.so.5.5.1)
> ==13702== by 0x7499074:
> QSGBatchRenderer::Renderer::uploadBatch(QSGBatchRenderer::Batch*) (in
> /usr/lib64/libQt5Quick.so.5.5.1)
> ==13702== by 0x74A4375: QSGBatchRenderer::Renderer::render() (in
> /usr/lib64/libQt5Quick.so.5.5.1)
> ==13702== by 0x74B00AE: QSGRenderer::renderScene(QSGBindable const&) (in
> /usr/lib64/libQt5Quick.so.5.5.1)
> ==13702== by 0x74B08FA: QSGRenderer::renderScene(unsigned int) (in
> /usr/lib64/libQt5Quick.so.5.5.1)
> ==13702== by 0x74C0DDD: QSGRenderContext::renderNextFrame(QSGRenderer*,
> unsigned int) (in /usr/lib64/libQt5Quick.so.5.5.1)
> ==13702== by 0x750ADCA: QQuickWindowPrivate::renderSceneGraph(QSize
> const&) (in /usr/lib64/libQt5Quick.so.5.5.1)
> ==13702== by 0x74DB78A: ??? (in /usr/lib64/libQt5Quick.so.5.5.1)
> ==13702== by 0x74DC890: ??? (in /usr/lib64/libQt5Quick.so.5.5.1)
> ==13702== by 0xA9D041B: QApplicationPrivate::notify_helper(QObject*,
> QEvent*) (in /usr/lib64/libQt5Widgets.so.5.5.1)
> ==13702== by 0xA9D58E5: QApplication::notify(QObject*, QEvent*) (in
> /usr/lib64/libQt5Widgets.so.5.5.1)

probably fixed in qt-5.5.2 nad qt-5.6.0
https://bugreports.qt.io/browse/QTBUG-48799

now i compiling qt5-qtdeclarative package with this patch

SOLVED!

these patches are needed:

for plasma-breeze - https://bugsfiles.kde.org/attachment.cgi?id=96588 (from https://bugs.kde.org/show_bug.cgi?id=357800)

for qt5-qtdeclarative - https://bugreports.qt.io/secure/attachment/51678/0001-Scene-Graph-Fixed-memory-leak-in-QSGBatchRenderer-Re.patch (from https://bugreports.qt.io/browse/QTBUG-48799)

thanks Antony, wojtek

I know it's not exactly appropriate to discuss distro-specifics here, but I know Rex Dieter is subscribed to this bug.
Of the two patches listed here as resolving this (very important) problem, one is for plasma-breeze and the other is for qt5-qtdeclarative. It looks like the latter is only committed against QT 5.6.

Rex (or other Fedora-type person), how can we communicate to the relevant Fedora package maintainers that we need a backport of this for QT 5.5.1 ?
(It looks like KDE bug 357800 for breeze is already in a 5.5.x context, and not a problem in master.)

Backported patches are now included in qt5-qtdeclarative-5.5.1-4 builds (and newer), see also
https://bodhi.fedoraproject.org/updates/?packages=qt5-qtdeclarative

Are there any openSUSE packagers of the QT components that are subbed to this bug report? If so, please backport it please.

As someone who understood some of the words in this thread, thank you to everyone involved in diagnosing and producing a fix for this. I look forward to the update on Manjaro :)

Thanks, Rex!
And thanks to all who diagnosed this.

Still getting this in plasmashell 5.6.4 (ubuntu backported) with insane cpu and ram usage, and often crashes when searching. Not sure if related.

I have quite a similar issue with Archilinux and plasma 5.7.4

Still seeing this with Kubuntu 16.10. plasma-shell using 1GB of RAM by the end of the day. Plasma 5.7.5

I also have this problem on Kubuntu 16.10 and created a new ticket #372384.