This bug seems to be similar to several others dealing with pixmap leaks, but I was unable to find any specifically about VMWare; if it should be combined into another one, I apologize for filing a duplicate. My problem is that KDE slows down to have almost unusably slow scrolling/image refresh after it's left overnight/during the day due to what I now believe is a pixmap leak. Using xrestop, which I just learned of, I see this progression, with about a 4K/sec increase constantly on only the plasma-desktop application: res-base Wins GCs Fnts Pxms Misc Pxm mem Other Total PID Identifier 1800000 84 84 1 42 1887 3734K 49K 3784K 31591 plasma-desktop 1800000 84 84 1 42 1924 3804K 50K 3854K 31591 plasma-desktop 1800000 84 84 1 42 1979 3908K 51K 3960K 31591 plasma-desktop etc... It occurs whenever VMWare Workstation 9.0.1 (running Win7 Pro 64-bit) is running, whether minimized or maximized. If I pause the VM, or close it, this stops, even if I leave the main VMWare window running. Although I can't way with certainty that this is the cause of the slowdown, it definitely seems to be from what I can see/what I've read about similar problems. I currently have no idea how to troubleshoot this further, and whether it's a Plasma, VMWare, or NVidia issue (or something else)... so any suggestions for how to narrow down the cause, or perhaps fix it, would be very much welcomed. I'm reporting it here first since plasma-desktop seems to be causing the pixmap leak, but perhaps that's due to a bug in the display driver or VMWare. In order to avoid logging out, I've been restarting it via these commands: kquitapp plasma-desktop && sleep 5 && plasma-desktop && killall kded4 && sleep 2 && kded4 &0 Though for various reasons this is not a great solution (the other commands besides restarting plasma were to deal with a bug related to blank entries in the System Tray, if I recall correctly). My hardware is as follows (I can provide more detail if needed): - 01:00.0 VGA compatible controller: NVIDIA Corporation GF114 [GeForce GTX 560 Ti] (rev a1) - Driver version 313.09 - Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz - 16 GB of RAM I've tried messing with various desktop effect settings, using XRender, disabling/re-enabling the nvidia pixmap cache, etc., but the only thing that seems to prevent this continual pixmap memory increase seems to be closing VMWare (which I don't want to do because I need to have both OSes running at the same time, most of the time). -Rand Reproducible: Always Steps to Reproduce: 1. Start xrestop 2. Notice the plasma-desktop "Pxm mem" and/or "Total" values, observe them to be steady 3. Start VMWare and launch a VM (in my case, Windows 7 Pro 64-bit, but happens on a Windows XP 32-bit image, or even just sitting in the 'BIOS' screen you get from F2 before the OS loads) 4. Observe the xrestop fields again, and notice that they are increasing (in my case, ~4 KB/sec) Actual Results: xrestop pixmap memory and total fields increase constantly by 4KB/sec, despite no activity in the VM. Plasma-desktop becomes slow (scrolling/image display mainly) and requires restarting. Expected Results: xrestop pixmap memory and total fields should remain constant or fluctuate around some average value, if nothing is happening in the VM. Plasma-desktop should not become slow and require restarting.
Though I have not tested this (and am not sure I want to, to avoid messing up my VMWare install), I suspect that the same issue would be visible using VMWare Player, which is free (http://www.vmware.com/products/player). If anybody has problems reproducing it and needs me to try this, let me know.
Just want to say I fail to reproduce it. After running netbsd in vmplayer for a few hours, I haven't notice significant pixmap leak in plasma-dekstop. Using vmware-player-5.0.1.894247 and the nouveau driver.
Thanks for testing that. I just noticed that the same version of VMWare player (5.0.1 build-894247) is installed by VMWare, and I am able to reproduce it there, but ONLY if I've first launched the real VMWare (I have a full version of Workstation) first. After I've launched that once, even if I don't run a VM in it, just booting an empty new VM in VMWare player can reproduce it (even if I close VMWare Workstation). No actual VM required, just waiting on the network boot ROM or BIOS screen produces the 4KB/sec increase. This also occurs for me with or without desktop effects turned on, and I also get it with a completely fresh .kde folder. I compiled and ran this to try and get some information about the pixmaps being created: http://people.redhat.com/caolanm/pixmaps/pixmap.c And I can see a lot of lines that occur when VMWare is running, and look like this: ===================== 0x1800f59 DESTROY 0x1800f66 CREATED 0x1800f63 DESTROY 0x1800f66 DESTROY 0x1800f69 CREATED 0x1800f6b CREATED 0x1800f70 CREATED 0x1800f70 DESTROY 0x1800f73 CREATED 0x1800f6b DESTROY 0x1800f69 DESTROY ===================== But I looked at around 1000 of these lines (they come in groups of about 10/sec), and did not see anything being created that was not also destroyed shortly thereafter, out of that sample. Does anybody have any suggestions as to how I can figure out *why* plasma-desktop's "Pxm mem" is increasing in xrestop? I tried running Valgrind on plasma-desktop, but I couldn't really see anything obvious (it did seem to find many other errors that are unrelated, as well as some 'definite' memory leaks, but I don't think it's what's happening here). I'm now running 313.18 NVidia drivers and seeing it on there as well. Next step will probably be to try some other versions, though changing those tends to be at least a little bit painful. If there's a easy to use utility to see what's going into the pixmap cache for a given process, that would be very helpful I think.
After reading a forum post on the KDE forums (http://forum.kde.org/viewtopic.php?f=67&t=110294), I tried hiding the VMWare icon from the System Tray widget. Now I no longer get the pixmap increases, though if I click the up arrow to show the hidden icons, it starts increasing again while it's open... so seems like the System Tray widget is really the problem, not plasma-desktop itself. If anybody has additional suggestions/wants me to gather more data, please let me know, but for now I think this probably solves my immediate issue of having to restart plasma-desktop repeatedly (though I'll see how it goes over the next few days).
I am not sure if this is relevant but I have the same symptoms with different triggers (no VMWare for a start). I my case, the trigger is Dropbox. When performing a sync, Dropbox displays an animated tray icon and that is causing X CPU usage to spike at 100% until the sync completes (when Dropbox returns to a static "green tick" icon). I only found this because I had an unreadable file in my Dropbox folder[1], which cased the sync to fail and the animated icon to remain. As with the OP, from a fresh boot it takes time for the problem to manifest itself and it gets gradually worse over time. I note that attempts to reproduce the problem have failed so I wonder whether the OP has Dropbox installed? [1] https://forums.dropbox.com/topic.php?id=98835
I do not have Dropbox installed on this PC, though as I had noted in one of the previous posts, it seemed to require having run the full VMWare Workstation app prior to running VMWare Player if I wanted to reproduce it with VMWare player (which I found pretty strange). I would definitely not be surprised if other apps cause this as well, though -- it's pretty slow to cause problems, and the end effect is a little bit subtle, though it's definitely a huge usability impact if you have to restart Plasma once a day (after hiding the icon, however, it no longer happens, so for now that's a decent workaround for me).
reproducible here on gentoo with kde 4.10.2 and vmware workstation 8.0.5
I agree that this does seem to be a duplicate of 314919, so marking it as such; even though the VMWare icon doesn't seem to blink at all, it's likely animated to show status updates all the time, perhaps it keeps showing the same icon to indicate status regardless of whether that status changes. *** This bug has been marked as a duplicate of bug 314919 ***