Bug 314919 - plasma-desktop is leaking memory in X if some icon in system tray is changing
Summary: plasma-desktop is leaking memory in X if some icon in system tray is changing
Status: RESOLVED FIXED
Alias: None
Product: plasma4
Classification: Unclassified
Component: widget-systemtray (show other bugs)
Version: 4.10.4
Platform: Mageia RPMs Linux
: NOR major with 180 votes (vote)
Target Milestone: ---
Assignee: Plasma Bugs List
URL:
Keywords:
: 216289 296473 313803 317961 (view as bug list)
Depends on:
Blocks:
 
Reported: 2013-02-11 17:37 UTC by Sander Lepik
Modified: 2015-02-28 14:29 UTC (History)
35 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sander Lepik 2013-02-11 17:37:17 UTC
Blinking systray icons are causing X to leak memory and plasma-desktop is to blame:

uptime: 23h
xrestop:
res-base Wins  GCs Fnts Pxms Misc   Pxm mem  Other   Total   PID Identifier    
2600000    64   63    0   87       54789   103910K   1287K 105197K  4300 plasma-desktop

In less than 24h it's using 100+ MB memory and the icon wasn't blinking most of the time. When the icon is not blinking then the used memory stays the same. As soon as icon starts to blink the memory usage in X also starts to grow.

Reproducible: Always

Steps to Reproduce:
1. Start some application ((he)xchat for example) that has blinking systray icon.
2. Make the icon blink
3. Watch plasma-desktop memory usage in xrestop.
Actual Results:  
Memory starts to leak.

Expected Results:  
X memory shouldn't leak.

I'm using nvidia driver and desktop effects are enabled (OpenGL).
Comment 1 Sander Lepik 2013-03-05 15:27:44 UTC
After few days X will be really slow and plasma-desktop crashes sometimes.
Comment 2 Mark Rogers 2013-04-04 11:35:38 UTC
I am also affected by this. Eventually I find that /usr/bin/X CPU usage risesover a period of hours to ~100% and the whole system becomes unusable. Stopping whatever is causing the icon to animate causes CPU to return to ~0%, restarting the icon animation sends CPU back to 100%.

My scenario is with Dropbox: during synchronisation it animates between two icons indicating that the sync is in progress. If the sync fails (eg a file is unreadable) Dropbox continues to animate the icons forever, resulting in the continued memory loss and eventual high X CPU usage. Eg, with Dropbox installed (with ~/Dropbox as the Dropbox sync folder):

# Create file as root, Dropbox will sync it fine as it can still read it
sudo touch ~/Dropbox/test.txt
# Change permissions to prevent reads, Dropbox will animate forever
sudo chmod 600 ~/Dropbox/test.txt
# Monitor with xrestop to confirm memory leak. When X CPU reaches high levels, confirm that
sudo chmod 644 ~/Dropbox/test.txt
# .. allows CPU to drop, and 
sudo chmod 600 ~/Dropbox/test.txt
# .. sends CPU back off into space. Finally
sudo rm ~/Dropbox/test.txt
# .. to get your system back.

Note that in my case I had to leave the system running for upwards of 48hrs to really see the dramatic slowdown, although memory leakage is evident via xrestop immediately.

See also:
https://forums.dropbox.com/topic.php?id=98835
http://forum.kde.org/viewtopic.php?f=67&t=110294

I initially had this problem with KDE as shipped with Kubuntu 12.10 with onboard AMD graphics (FOSS drivers). Before narrowing the problem down I upgraded to Kubuntu 13.04 (beta), installed an nVidia G210 graphics card (first FOSS then proprietary drivers). All gave me the same symptoms so I don't think this is related to a graphics driver or specific hardware. My PC has 16GB RAM and never goes above about 8GB used even when the system has ground to a halt with X CPU usage at 100%.

In case this helps (probably not!):
The Dropbox animation uses files from ~/.dropbox-dist/images/hicolor/16x16/status/. Removing one of the busy icons (eg dropboxstatus-busy2.png) and restarting dropbox (dropbox stop/dropbox start) generates the following exceptions:
----
Traceback (most recent call last):
  File "arch/linux/tray_icon_wx.py", line 134, in busy_tick
  File "wx/_windows.py", line 1657, in SetIcon
wx._core.PyAssertionError: C++ assertion "Ok()" failed at ./src/gtk/bitmap.cpp(876) in GetPixbuf(): invalid bitmap
----
Triggering the sync issue (chmod 600 as above) results in the same exception repeatedly as the icons are animated. xrestop indicates that the memory leak is continuing to leak. However removing both of the busy icons and restarting Dropbox does not generate an exception and xrestop reports no memory loss when the sync issue is triggered.

I only mention this in case it indicates a problem in wx rather than plasma-desktop. I don't know whether the other apps that trigger this are also wx based.
Comment 3 Jekyll Wu 2013-04-07 02:19:16 UTC
*** Bug 317961 has been marked as a duplicate of this bug. ***
Comment 4 Eevee 2013-04-07 04:11:21 UTC
Discoveries I reported in bug 317961:

- This has been around a long time; at least a year.
- It's not specifically blinking.  Any icon change leaks the old icon.
- KDE apps don't seem to be affected.  I've observed the leak it in Pidgin, uim-toolbar-gtk-systray, and WhatPulse; other reports mention X-Chat derivatives, Dropbox, and VMWare.  All of these are GTK+ applications.
- Use of desktop effects is irrelevant.  Suspect video card and drivers are, too; anyone with a non-nvidia card is welcome to prove me wrong.
- Setting all GTK+ systray icons to Hidden, disabling their systray icons, or removing the system tray plasmoid all prevent further leaking.
- `killall plasma-desktop && plasma-desktop` has been the simplest way I've found to reset the picture count and unsuck the desktop.
- The most accessible way to reproduce is to run Pidgin, sign in, turn on its systray icon, and change status a few times.

Bug 313803 looks like a clear duplicate.
Comment 5 Sander Lepik 2013-04-07 06:28:23 UTC
Last time when it worked w/o problems was in KDE 4.6. I didn't test KDE 4.7 but in 4.8 it's leaking.
Skype seems to cause leaking too.
It's also leaking with Intel graphics card.
Killing plasma-desktop is only part of the workaround. It won't bring back leaked memory :/ For that you have to log in and out.
Comment 6 Rand Kmiec 2013-04-07 11:23:46 UTC
*** Bug 313803 has been marked as a duplicate of this bug. ***
Comment 7 Till Schäfer 2013-04-22 10:10:53 UTC
*** This bug has been confirmed by popular vote. ***
Comment 8 Bobby Kent 2013-04-22 13:04:56 UTC
Not sure if it's related, though I noticed the first value in /proc/sys/fs/file-nr rise and rise and rise with some apps when they are in the System Tray, (Knutclient being one such app).  I'm on KDE 4.10.1, kernel 3.7.10, knutclient 1.0.4, xorg-drivers 1.13, xf86-video-ati 7.0.0, mesa 9.0.1, with Gentoo as the distro.  I do not see this behavior with some other apps (e.g. vlc 2.0.5)

Another oddity, to reset the file-nr value back to "normal", I could logout/login to KDE, though when I do this, a later reboot via kexec (2.0.2) results in a kernel crash early in the boot process.  A reboot via kexec from the first login to KDE does not result in a kernel crash on boot.
Comment 9 Michael Lashkevich 2013-04-30 20:51:52 UTC
I confirm the bug (OpenSUSE 12.3, xf86-video-intel, kde 4.10.2). The number of Misc picture and Pixmap memory is growing (and never lowering) with any change on the desktop (appearing/hiding of a panel, appearing/hiding of system notifications, appearing/hiding of the hidden items in the system tray etc.) so that I have 300MB in 2-3 hours.
Comment 10 Michael Lashkevich 2013-04-30 20:57:15 UTC
PS. I use xrestop to constantly follow the changes. Even switching windows leads to growing number in the misc column and pixmaps memory usage for the plasma-desktop.
Comment 11 Rascas 2013-05-10 08:53:51 UTC
I can confirm this bug (or it is other?) in Archlinux, kde4.10.3, nvidia 319.17, kernel 3.9, Xorg 1.14.1
Exactly same symptons of Michael Lashkevich.
Comment 12 yjcoshc 2013-05-24 15:24:06 UTC
I can reproduce this bug in opensuse 12.3, kde 4.10.3, nvidia 319.17
Comment 13 Roberto Ragusa 2013-06-13 07:15:50 UTC
Confirmed KDE 4.10.3 on Fedora 17. Triggered by Pidgin, VMware workstation.

xrestop line:

1600000    68   65    1  101 799297    24365K  18737K  43103K  3266 plasma-desktop

800,000 leaked pixmaps!
Comment 14 oracle2b 2013-06-13 12:01:15 UTC
confirmed on pclinuxos using 4.10.4. 

relevant thread http://forum.kde.org/viewtopic.php?f=67&t=110294
Comment 15 yjcoshc 2013-06-21 11:14:26 UTC
This bug is still reproducable in KDE 4.10.4. It seems that copying large file for a long time in dolphin can also cause X pixmap memory leaks in plasma, maybe this is because the widget is flashing in the panel.
Comment 16 Sander Lepik 2013-06-21 11:22:48 UTC
Wondering.. Is there anyone behind the Plasma Bugs List or is this some empty and old list that no one follows :/
Comment 17 Rascas 2013-06-21 11:29:25 UTC
@chen haochuan: Yes.
I thinks this is one of the most serious bugs im KDE. It is not fixed in KDE 4.11 beta...
Comment 18 topaz 2013-06-24 13:56:21 UTC
Hi all,
I've been bothered with this bug for a while now. 
I think I got a new trigger to get it appear in a very reliable way.

Scenario:
- ensure you have at least 2-3 icons hidden in the systray "Show hidden icons" (the up arrow before the hour)
- open a konsole and run a xrestop into it. ensure this window is viewable,
- click on the up arrow in the systray and slide between icons using your mouse (go up and down for a while)

Obervsations:
- if you stop moving the mouse over hidden icons, the misc pixmaps count is somehow stable in xrestop for plasma-desktop.
- if you move the mouse between icons, then the misc pixmap count is constantly increasing.

My 50 cents.
Topaz
Comment 19 yjcoshc 2013-06-26 03:36:44 UTC
It seems that it has multiple memory leaks:
1.Blinking icons in the tray.
2.Show/Hidden calendar/kickoff.(While the calendar shows up, the pixmem usage increases, but it doesn't decrease when it is hidden.)
3.Switch windows.(I switch between firefox and konsole and each time the pixmem usage grows about 4K and never decreases.)
Comment 20 mathew 2013-06-26 14:51:40 UTC
I get chronic memory leakage in X which in my case seems to be something to do with Google Chrome and/or VMware Workstation — however, that could just be because those are the programs I leave running the longest. I too am using the nVidia proprietary driver.

Generally if I quit Chrome and VMware completely I can ameliorate the situation, but eventually X.org starts chewing 100% CPU and the only option is to restart.

Right now, running xrestop, plasma-desktop has 207620 in the Misc column, and it's increasing by 3 points every couple of seconds, even if I just sit and watch it. It certainly looks to me like there's a leak in plasma-desktop.

I'd love to help track down the bug, if there's anything I can do.

Kubuntu 12.04 LTS, plasma-desktop 4.10.4 via Ubuntu PPA.

Now at 207946...
Comment 21 mathew 2013-06-26 15:06:11 UTC
Aha! If I stop my VMware image, the leakage stops. If I use VMware Player instead of VMware Workstation, no leakage. One key difference between the two is that VMware Workstation puts an icon in the system tray to indicate the running state of the VM.

So this supports the idea that it's something to do with systray icons changing. My guess is that VMware updates the icon every second or two even if it doesn't strictly need to.

And in the mean time, if I use VMware Player for my VMs, I can hopefully avoid having to reboot so often...
Comment 22 Rael Gugelmin Cunha 2013-06-26 16:37:20 UTC
Any relation with this bug? https://bugs.kde.org/show_bug.cgi?id=309464
Comment 23 Rex Dieter 2013-06-26 17:57:35 UTC
no evidence of relation (yet).
Comment 24 Gil Vidals 2013-06-29 14:16:30 UTC
I am running a desktop with KDE 4.9.5 with ATI Radeon proprietary drivers for the HD 5700 graphics card. This memory leak was rendering my system unusable in less than 8 hours. I was on the verge of installing a different distro when I read about this bug. I noticed my colleagues did not have a blinking nagstamon icon in their systray, so I disabled mine and the memory leak issue is manageable now.

I sure hope a developer will pursue this bug and squash it soon.
Comment 25 Jiri Slaby 2013-07-01 12:56:11 UTC
This is a dup of bug 216289, I would say.
Comment 26 Steven Noonan 2013-07-01 13:04:12 UTC
I think the other bug definitely describes the same issue, but bug 314919 has far more attention (230 votes, 24 CCs) than bug 216289 (81 votes, 12 CCs). It also appears that bug 216289 is assigned to the Kopete developers, which isn't the right group to handle this (as _any_ animated systray icon triggers the issue). This bug also seems to have better direction and more technical detail in the comment log. Despite the fact that 216289 was reported first, I'd say the other is a duplicate of this one.
Comment 27 Andreas Hartmetz 2013-07-02 16:41:24 UTC
Git commit ec8e405ca447ba5bc5a9f6a2a12e2fa90412a0d4 by Andreas Hartmetz.
Committed on 02/07/2013 at 16:35.
Pushed by ahartmetz into branch 'master'.

Fix pixmap leak when the tray icon changes (e.g. when it's animated).

This could easily leak 4KB/second of X pixmap memory.
All the actual difference comes from the QPixmap::ExplicitlyShared
argument, the rest is making some wonky-looking but working code look
less wonky.

M  +10   -9    plasma/generic/applets/systemtray/protocols/fdo/x11embedcontainer.cpp

http://commits.kde.org/kde-workspace/ec8e405ca447ba5bc5a9f6a2a12e2fa90412a0d4
Comment 28 topaz 2013-07-02 17:16:09 UTC
Thanks Andreas, this one was really driving me mad.
Comment 29 Andreas Hartmetz 2013-07-02 17:25:49 UTC
*** Bug 216289 has been marked as a duplicate of this bug. ***
Comment 30 Andreas Hartmetz 2013-07-02 17:37:16 UTC
*** Bug 296473 has been marked as a duplicate of this bug. ***
Comment 31 Bobby Kent 2013-07-03 01:15:23 UTC
Many thanks Andreas.  Patched my installation with the fix about and so far it looks like it's done the trick.
Comment 32 David Faure 2013-07-03 15:33:53 UTC
Git commit 2c810db3e41d56ad7dd8ec3436f3cf3abcc31983 by David Faure, on behalf of Andreas Hartmetz.
Committed on 02/07/2013 at 16:35.
Pushed by dfaure into branch 'KDE/4.10'.

Fix pixmap leak when the tray icon changes (e.g. when it's animated).

This could easily leak 4KB/second of X pixmap memory.
All the actual difference comes from the QPixmap::ExplicitlyShared
argument, the rest is making some wonky-looking but working code look
less wonky.
(cherry picked from commit ec8e405ca447ba5bc5a9f6a2a12e2fa90412a0d4)

M  +10   -9    plasma/generic/applets/systemtray/protocols/fdo/x11embedcontainer.cpp

http://commits.kde.org/kde-workspace/2c810db3e41d56ad7dd8ec3436f3cf3abcc31983
Comment 33 diogomsantos 2013-07-03 20:22:09 UTC
This bug is only partially fixed. The issue in comment 9 is not fixed.

Its pretty easy to reproduce.

1-open System Monitor
2-open other window, for example konsole

Switch between them and watch the memory usage of plasma-desktop starts growing.  You can see the leak in xrestop too.

Another ways to reproduce it:

-Just click several times in the arrow "Show hidden icons" in system tray. 

-Just hover with the mouse between different programs opened in task manager, to show a tooltip.

Watch the memory usage of plasma-desktop growing and never lowering.
Comment 34 Eevee 2013-07-08 19:01:15 UTC
No leaks in sight under 4.10.5, thanks!
Comment 35 relative.prime 2013-07-10 23:53:44 UTC
This bug has been plaguing me since before last November, from OpenSuse 12.1 through 12.3 with every version of the Nvidia driver from  ~304.51 to 319.23. I've spent several hours trying to resolve this. Found this bug report, verified it applied to my system, disabled Dropbox sync when not needed and resolved the issue in minutes. Thanks, and looking forward to the above patch fixing the issue in the next KDE release!
Comment 36 diogomsantos 2013-07-11 09:26:55 UTC
Well some ppl are happy but kde its still not ready to server deployment...
I can reproduce this leaks in arch, fedora and opensuse...

I cant have KDE in a simple server, always on, because after 2 or 3 days of use, i easily get plasma-desktop using 300 or MB of RAM. 

If you see through, almost any action that you do with plasma there is a memory leak...

Maybe its better to fill another bug report, because maybe its a different bug, but yeah, its really frustating... and i just dont know (im not a programmer) how to help to fix it...

I can put some logs, buts its so evident, and easily reproducible, that i think its unnecessary...
Comment 37 Sander Lepik 2013-07-11 09:39:23 UTC
(In reply to comment #36)
> Maybe its better to fill another bug report, because maybe its a different
> bug, but yeah, its really frustating... and i just dont know (im not a
> programmer) how to help to fix it...

Yes, please do so, as this bug really seems to be fixed. Changing icons are not leaking memory anymore - and that's the main problem in this bug. No point to mix different bugs.
Comment 38 mathew 2015-01-12 14:59:30 UTC
I believe someone has reintroduced this problem.

If I have SpiderOak running (changing icons regularly), Plasma leaks memory and eventually crashes in less than 24 hours.

If I don't have SpiderOak running, Plasma will last an entire weekend.
Comment 39 Rex Dieter 2015-01-12 15:00:58 UTC
same as comment #37, please open a new bug
Comment 40 mathew 2015-01-12 16:13:07 UTC
There are two new bugs already open which seem to be this one again: #342374 and #335202. I've posted comments on them pointing back to here.
Comment 41 Rex Dieter 2015-01-12 16:27:17 UTC
Those are vague/generic reports of plasma-desktop growing memory use.  No evidence the cause is due to systray icons (imho).  Again, I'd strongly urge you to consider opening a new (specific) bug.
Comment 42 mathew 2015-01-12 16:31:52 UTC
Unfortunately I don't have time to write a program to rapidly change system tray icons in order to demonstrate the problem. I was hoping that someone else could, given that that's likely the trigger.
Comment 43 Fazl Halm 2015-01-13 08:12:18 UTC
One way to reproduce this is by just copying some files from a folder to anywhere else then the memory usage of plasma-dekstop will shoot up due to the blinking tray icon while copying process is running.
Comment 44 Alberto 2015-01-21 08:23:13 UTC
Not sure about whether it's the same issue, but since I've upgraded to Fedora 21 (KDE 4.14.3-4) I've been experiencing +huge+ memory leaks. The scenario is as follows:

- At system startup (monitoring with htop) VIRT usage by kdeinit4: plasma-desktop is just about 3000MB. RES about 300MB, SHR about 100MB
- Memory usage keeps increasing. After some hours, VIRT can reach up to 16GB(!) which leads to high swap usage. However, xrestop doesn't show any increments.
- I've not been able to relate it to any particular application, but it seems that 'heavy' ones (like Eclipse) take a high toll on memory usage. However, after closing all open apps, VIRT (and SHR/RES) don't get back to normal. The only way to reduce them is to reset X system.
Comment 45 Matt W 2015-01-27 15:27:24 UTC
Alberto,

There is discussion about this bug here, as well:

https://bugs.kde.org/show_bug.cgi?id=342374
Comment 46 Alberto 2015-01-27 15:31:24 UTC
Thanks, Matt. I've copied my report there too.
Comment 47 Vladislav Vorobiev 2015-02-28 14:29:35 UTC
This bug is also in my debian KDE

$ plasma-desktop -v
Qt: 4.8.6
KDE Development Platform: 4.14.2
Plasma Desktop Shell: 4.11.13

It makes kde unusable for normal users!
It's not fixed