Bug 314919

After few days X will be really slow and plasma-desktop crashes sometimes.

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.

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

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.

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.

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

*** This bug has been confirmed by popular vote. ***

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.

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.

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.

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.

I can reproduce this bug in opensuse 12.3, kde 4.10.3, nvidia 319.17

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!

confirmed on pclinuxos using 4.10.4. 

relevant thread http://forum.kde.org/viewtopic.php?f=67&t=110294

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.

Wondering.. Is there anyone behind the Plasma Bugs List or is this some empty and old list that no one follows :/

@chen haochuan: Yes.
I thinks this is one of the most serious bugs im KDE. It is not fixed in KDE 4.11 beta...

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

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.)

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...

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...

Any relation with this bug? https://bugs.kde.org/show_bug.cgi?id=309464

no evidence of relation (yet).

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.

This is a dup of bug 216289, I would say.

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.

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

Thanks Andreas, this one was really driving me mad.

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

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

Many thanks Andreas.  Patched my installation with the fix about and so far it looks like it's done the trick.

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

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.

No leaks in sight under 4.10.5, thanks!

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!

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...

(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.

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.

same as comment #37, please open a new bug

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.

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.

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.

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.

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.

Alberto,

There is discussion about this bug here, as well:

https://bugs.kde.org/show_bug.cgi?id=342374

Thanks, Matt. I've copied my report there too.

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