Bug 344879 - memory leak in plasmashell - huge ram usage
Summary: memory leak in plasmashell - huge ram usage
Status: RESOLVED FIXED
Alias: None
Product: plasmashell
Classification: Plasma
Component: general (show other bugs)
Version: 5.2.0
Platform: Arch Linux Linux
: NOR normal
Target Milestone: 1.0
Assignee: Marco Martin
URL:
Keywords:
: 345711 (view as bug list)
Depends on:
Blocks:
 
Reported: 2015-03-05 18:19 UTC by metsys
Modified: 2022-12-28 20:04 UTC (History)
65 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Plasma memory usage smap export (1.00 MB, text/plain)
2015-05-02 08:32 UTC, bugzy
Details
ksysguard detailed view of plasmashell memory usage (124.87 KB, image/png)
2015-05-02 08:33 UTC, bugzy
Details
ksysguard view of plasmashell and xorg memory usage (51.07 KB, image/png)
2015-05-02 08:34 UTC, bugzy
Details
System Tray Items (54.00 KB, image/png)
2015-05-02 22:50 UTC, bugzy
Details
Every time crash on ram usage around 300M (28.00 KB, text/plain)
2015-06-13 06:33 UTC, Anthony Fieroni
Details
With Qt 5.4.2 debug symbols (39.20 KB, text/plain)
2015-06-20 03:33 UTC, Anthony Fieroni
Details
valgrind with memory leak (2.66 MB, application/x-gzip)
2015-11-09 10:57 UTC, wojtek
Details
xrestop (112.92 KB, image/png)
2015-12-11 12:28 UTC, André M
Details
xrestop of valgrind session (104.04 KB, image/png)
2015-12-13 02:25 UTC, André M
Details
Xorg's pmap of previous session, without valgrind, around 1.3G (89.36 KB, text/plain)
2015-12-13 02:28 UTC, André M
Details
Xorg's pmap of valgrind+debug symbols session (202.85 KB, text/plain)
2015-12-13 02:30 UTC, André M
Details
valgrind log of Xorg with debug symbols, from start to end (1.14 MB, text/x-log)
2015-12-13 02:32 UTC, André M
Details

Note You need to log in before you can comment on or make changes to this bug.
Description metsys 2015-03-05 18:19:28 UTC
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 ))
Comment 1 metsys 2015-03-05 18:23:09 UTC
corrupted link, here is right: 
http://rghost.net/private/8Qgfs2rd4/f05d5b1e87aad02d863e9009e864c8da
Comment 2 Vova 2015-03-07 20:28:40 UTC
Welcome into JS world! :)
Comment 3 metsys 2015-03-09 13:52:09 UTC
More plasma Debug http://rghost.net/private/8PVkCKVKd/6c607378e1060bcaf6f2935b287335cd
Comment 4 NForce 2015-03-12 19:16:29 UTC
I see the same exact problem on my Gentoo 64bit laptop.
Plasma 5.2.1, KF5.7, Qt 5.4.1
Comment 5 H.H. 2015-03-19 12:48:57 UTC
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.
Comment 6 Jan 2015-03-20 12:41:26 UTC
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
Comment 7 Andreas Berger 2015-03-22 06:31:26 UTC
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.
Comment 8 David Edmundson 2015-03-22 17:58:34 UTC
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.
Comment 9 H.H. 2015-03-22 18:13:58 UTC
It happens on two different machines for me, one is an intel GM45 Express with a recent i915 driver
Comment 10 Andreas Berger 2015-03-22 18:22:02 UTC
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.
Comment 11 metsys 2015-03-22 20:11:54 UTC
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
Comment 12 metsys 2015-03-22 21:28:34 UTC
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
Comment 13 metsys 2015-03-23 13:30:17 UTC
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
Comment 14 Jan 2015-03-23 14:17:59 UTC
It happens to me mostly some time after the screen was locked, but I can't confirm it is really related to each other.
Comment 15 Marco Martin 2015-03-31 09:09:00 UTC
*** Bug 345711 has been marked as a duplicate of this bug. ***
Comment 16 MaNNa 2015-04-18 09:36:08 UTC
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.
Comment 17 David Edmundson 2015-04-18 10:01:46 UTC
Transmission-qt makes plasmashell use more memory?

Does it have a system tray icon? Does that icon do anything "odd"?
Comment 18 MaNNa 2015-04-18 13:06:16 UTC
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.
Comment 19 MaNNa 2015-04-18 13:09:28 UTC
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.
Comment 20 Alvaro Soliverez 2015-04-30 23:01:04 UTC
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.
Comment 21 bugzy 2015-05-02 08:31:15 UTC
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.
Comment 22 bugzy 2015-05-02 08:32:25 UTC
Created attachment 92365 [details]
Plasma memory usage smap export
Comment 23 bugzy 2015-05-02 08:33:26 UTC
Created attachment 92366 [details]
ksysguard detailed view of plasmashell memory usage
Comment 24 bugzy 2015-05-02 08:34:33 UTC
Created attachment 92367 [details]
ksysguard view of plasmashell and xorg memory usage
Comment 25 bugzy 2015-05-02 08:44:25 UTC
I forgot to add that I am using Fedora packages:
Fedora 21
Linux 3.19.5-200.fc21
KDE Plasma 5.3
Comment 26 bugzy 2015-05-02 09:11:31 UTC
Also I do not have transmission-qt or transmission installed or running
Comment 27 David Edmundson 2015-05-02 18:54:13 UTC
bugzy, can you list what things you do have in the sysem tray?
Comment 28 bugzy 2015-05-02 22:47:04 UTC
@ 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.
Comment 29 bugzy 2015-05-02 22:50:31 UTC
Created attachment 92380 [details]
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
Comment 30 David Edmundson 2015-05-07 22:05:17 UTC
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
Comment 31 bugzy 2015-05-08 15:37:35 UTC
@ 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.
Comment 32 ycollet 2015-05-28 06:40:53 UTC
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).
Comment 33 ycollet 2015-05-28 06:42:50 UTC
The version of kde installed under Fedora 22 is kf5 - 5.10.0
Comment 34 root 2015-05-30 16:24:04 UTC
Same problem here.
Plasma 5.3.1
ArchLinux
Intel video.
Comment 35 ycollet 2015-06-01 08:02:18 UTC
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 %.
Comment 36 Daniel Boff 2015-06-05 16:42:26 UTC
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?
Comment 37 alexzkhr 2015-06-06 11:50:44 UTC
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).
Comment 38 alexzkhr 2015-06-06 12:23:58 UTC
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.
Comment 39 Hussam Al-Tayeb 2015-06-06 21:26:58 UTC
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.
Comment 40 Anthony Fieroni 2015-06-13 06:33:32 UTC
Created attachment 93146 [details]
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
Comment 41 bugzy 2015-06-13 07:03:16 UTC
@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.
Comment 43 Nick Malakhov 2015-06-15 06:59:28 UTC
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.
Comment 44 Anthony Fieroni 2015-06-20 03:33:29 UTC
Created attachment 93253 [details]
With Qt 5.4.2 debug symbols
Comment 45 miku84 2015-06-24 18:08:03 UTC
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.
Comment 46 Hussam Al-Tayeb 2015-06-24 22:38:20 UTC
Since this is likely because of the use of JS, any way to implement garbage collecting?
Comment 47 Marc González Majoral 2015-06-25 06:46:58 UTC
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.
Comment 48 Filip Sobalski 2015-06-25 20:09:31 UTC
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.
Comment 49 David V 2015-06-26 22:34:50 UTC
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.
Comment 50 David Edmundson 2015-07-03 06:28:49 UTC
>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.
Comment 51 Anthony Fieroni 2015-07-03 06:59:37 UTC
(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.
Comment 52 David Edmundson 2015-07-03 07:06:06 UTC
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.
Comment 53 miku84 2015-07-03 07:09:16 UTC
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."
Comment 54 David Edmundson 2015-07-03 07:20:09 UTC
Yes.
Comment 55 MaNNa 2015-07-03 09:06:26 UTC
(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
Comment 56 Anthony Fieroni 2015-07-03 09:10:08 UTC
(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.
Comment 57 noreguards 2015-07-12 08:37:00 UTC
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.
Comment 58 alexzkhr 2015-07-12 08:39:03 UTC
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.
Comment 59 Anthony Fieroni 2015-07-13 07:34:15 UTC
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?
Comment 60 Daniel Boff 2015-07-16 20:21:39 UTC
Yes, RAM usage doesn't increase anymore for me. Would be interesting what the cause was
Comment 61 H.H. 2015-07-16 21:16:01 UTC
For me this is also solved now
Comment 62 David M 2015-08-30 14:50:56 UTC
With Kf5.13 and plasma 5.4 the problem seems to have returned for me.  plasmashell is currently using 2.4G.
Comment 63 mrDoctorWho 2015-09-02 20:35:48 UTC
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.
Comment 64 Bernd Weigelt 2015-09-18 07:31:49 UTC
I have the same problem with 5.14 and Qt 5.5 on two systems.
Comment 65 Hussam Al-Tayeb 2015-09-18 07:50:21 UTC
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)
Comment 66 Bernd Weigelt 2015-09-19 08:01:54 UTC
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
Comment 67 Dan Mac 2015-10-19 22:14:02 UTC
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 :)
Comment 68 Hussam Al-Tayeb 2015-10-19 22:19:13 UTC
(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.
Comment 69 Grozdan 2015-11-02 15:08:27 UTC
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.
Comment 70 alexzkhr 2015-11-02 15:10:09 UTC
ok.. i will NOT unfreeze 4.8.6 KDE yet i did and it goes...on arch
Comment 71 alexzkhr 2015-11-02 15:10:28 UTC
ok.. i will NOT unfreeze 4.8.6 KDE yet i did and it goes...on arch
Comment 72 alexzkhr 2015-11-02 15:11:23 UTC
(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
Comment 73 Grozdan 2015-11-07 14:10:34 UTC
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
Comment 74 wojtek 2015-11-09 10:57:43 UTC
Created attachment 95400 [details]
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.
Comment 75 Nick Malakhov 2015-11-11 06:56:44 UTC
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?
Comment 76 Dmitry 2015-11-11 10:15:27 UTC
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.
Comment 77 wojtek 2015-11-11 19:17:12 UTC
(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 ? :)
Comment 78 David Edmundson 2015-11-13 21:04:07 UTC
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.
Comment 79 Grozdan 2015-11-13 21:08:17 UTC
@David Edmunson

I don't have that freetype2 pkg installed on my system, but memory still rises
Comment 80 wojtek 2015-11-20 20:46:44 UTC
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).
Comment 81 André M 2015-12-09 17:21:49 UTC
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.
Comment 82 Hussam Al-Tayeb 2015-12-09 17:26:29 UTC
(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?
Comment 83 André M 2015-12-09 17:28:56 UTC
(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).
Comment 84 André M 2015-12-10 19:35:00 UTC
(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).
Comment 85 Anthony Fieroni 2015-12-11 04:53:43 UTC
Provide output of xrestop.
Comment 86 André M 2015-12-11 12:28:56 UTC
Created attachment 95993 [details]
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.
Comment 87 AnAkkk 2015-12-12 18:43:01 UTC
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.
Comment 88 André M 2015-12-12 21:57:40 UTC
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?
Comment 89 André M 2015-12-13 02:25:02 UTC
Created attachment 96025 [details]
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.
Comment 90 André M 2015-12-13 02:28:34 UTC
Created attachment 96026 [details]
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)
Comment 91 André M 2015-12-13 02:30:03 UTC
Created attachment 96027 [details]
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.
Comment 92 André M 2015-12-13 02:32:59 UTC
Created attachment 96028 [details]
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.
Comment 93 Georg Grabler 2015-12-20 21:42:56 UTC
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.
Comment 94 Andrew Gaydenko 2015-12-21 00:15:51 UTC
I have got - not scientific :) - feeling the leak is correlated with workspace background: using solid color helps.
Comment 95 Georg Grabler 2015-12-21 02:00:52 UTC
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.
Comment 96 Hussam Al-Tayeb 2015-12-21 02:24:55 UTC
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.
Comment 97 Georg Grabler 2015-12-21 23:11:30 UTC
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.
Comment 98 AnAkkk 2015-12-21 23:13:51 UTC
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.
Comment 99 Georg Grabler 2015-12-21 23:16:36 UTC
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.
Comment 100 Andrew Gaydenko 2015-12-21 23:35:33 UTC
(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.
Comment 101 Hussam Al-Tayeb 2015-12-22 00:02:51 UTC
(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?
Comment 102 Hussam Al-Tayeb 2015-12-23 21:17:22 UTC
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).
Comment 103 Elizabeth Myers 2015-12-24 18:12:03 UTC
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.
Comment 104 Hussam Al-Tayeb 2015-12-24 18:26:18 UTC
(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
Comment 105 Elizabeth Myers 2015-12-24 18:54:49 UTC
(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.
Comment 106 Hussam Al-Tayeb 2015-12-24 19:05:33 UTC
(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).
Comment 107 AnAkkk 2015-12-24 22:16:48 UTC
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.
Comment 108 André M 2015-12-28 00:00:10 UTC
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.
Comment 109 Elizabeth Myers 2015-12-28 08:22:26 UTC
I've tried another compositing WM (xfwm4) and I have no leaks. It definitely seems to be something KDE is doing.
Comment 110 painless roaster 2016-01-21 18:14:08 UTC
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
Comment 111 Rex Dieter 2016-01-21 18:18:05 UTC
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.
Comment 112 Anthony Fieroni 2016-01-21 19:45:40 UTC
(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.
Comment 113 painless roaster 2016-01-22 09:30:58 UTC
(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.
Comment 114 painless roaster 2016-01-22 10:05:48 UTC
(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.
Comment 115 painless roaster 2016-01-22 10:54:27 UTC
(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 .
Comment 116 Troy Volin 2016-01-22 16:56:05 UTC
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.
Comment 117 Anthony Fieroni 2016-01-27 07:34:07 UTC
(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?
Comment 118 painless roaster 2016-01-27 11:30:48 UTC
(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
Comment 119 painless roaster 2016-01-27 17:05:00 UTC
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)
Comment 120 wojtek 2016-01-27 17:36:04 UTC
(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
Comment 121 painless roaster 2016-01-27 17:52:51 UTC
now i compiling qt5-qtdeclarative package with this patch
Comment 123 Troy Volin 2016-01-27 19:04:09 UTC
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.)
Comment 124 Rex Dieter 2016-01-28 18:40:26 UTC
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
Comment 125 Grozdan 2016-01-28 18:59:10 UTC
Are there any openSUSE packagers of the QT components that are subbed to this bug report? If so, please backport it please.
Comment 126 Dan Mac 2016-01-28 20:43:16 UTC
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 :)
Comment 127 Troy Volin 2016-01-28 22:05:33 UTC
Thanks, Rex! 
And thanks to all who diagnosed this.
Comment 128 Dan Dart 2016-06-08 17:37:05 UTC
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.
Comment 129 Olivier Becquaert 2016-09-11 19:42:15 UTC
I have quite a similar issue with Archilinux and plasma 5.7.4
Comment 130 Nick 2016-10-18 02:37:38 UTC
Still seeing this with Kubuntu 16.10. plasma-shell using 1GB of RAM by the end of the day. Plasma 5.7.5
Comment 131 Lastique 2016-11-12 11:48:54 UTC
I also have this problem on Kubuntu 16.10 and created a new ticket #372384.