I thought my posting was quite clear:

- This happens with nouveau and all three versions of the nvidia driver
- This happens with two different video boards in the machine.
- I believe I tried turning off OpenGL and moving to Xrender with no impact, but that was over a month ago and I won't swear to it.

You will have a hard time convincing me it's not 314919

The ONLY thing that fixes the leak is to prevent Vmware from displaying a task-bar icon and shutting Dropbox. As soon as I start either of those the memory starts ramping up.

So, at the risk of repeating myself, did the fix get into an official release of KDE and if so, which one? Thanks much.

I got slightly confused by the post that stated

I've been running the new driver for about two days and memory use by xorg has stabilized at 265M virt, 145M res - give or take 2/3 M. This has never happened before.

after installing nvidia-325

Also - quoting myself - a leak in a client should and would be visible in xrestop. The pixmaps would be either assigned to the particular client (like "plasma-desktop") which allocated them on the server, or "unknown" in doubt (if the allocating client exited and left the pixmaps)

Bug #314919 is declared fixed for 4.10.5 and up (and the linked commit does fix a leak in the fdo systray implementation for sure)

There's another bug claimed in bug #314919 comment #9, but that seems to be not systray specific (and esp. not fdo systray). This issue as well is claimed to be visible in xrestop.

I probably did not know what to look for or expect in xrestop. I was thinking that something in its listing would clearly be picking up on the order of hundreds of megabytes, but that was never the case. At worst, kwin would grow by perhaps 10MB as reported by xrestop as xorg piled on over 200MB as reported by 'top'.

Would you have expected to see this 200+ MB of leakage appear directly in xrestop? It definitely was not.

At any rate, I've brought this to the attention of the Ubuntu maintainers in the hopes that they will backport the fix to kde 4.8.5 and release as a fix to 12.04 LTS. In theory it might be possible to install kde 4.10.5 on this system, but I am not up for the adventure of building it from scratch. Worst case, I'll have to ensure that Dropbox and Vmware never display on the task bar. Vmware is a no-brainer, but I'm not sure that it's possible to have the Dropbox sync tool run with its icon in the bar.

Yupp, if a client leaks pixmaps on the server, the server should still be aware of them and the aggregation line should reflect that:

Pixmaps: 8191K total, Other: 32K total, All: 8224K total

This means there're ~8MB allocated on the server - most of them pixmaps.
This does not necessarily mean you'll see 8MB in top or so - the memory could be allocated on VRAM.

Also please be aware that the virtual memory in "top" does not say anything about the actual memory demand of the process.
The most relevant number about the overall memory load is

Code: Select all

grep "Active(anon)" /proc/meminfo

The most speaking number in top is RES, but it's far more complicated than this (because of the shared memory) - yet it's still a good relative measure.

I wasn't placing much importance on the virtual memory use. The RES set for the server would approach 400MB after a week of operation. Once it grew past about 300MB things would start slowing down dramatically. Nothing on that order of magnitude ever appeared in xrestop. Since it was so clearly caused by the non-KDE pixmaps on the task bar, I wonder why it didn't show? At any rate, I'm delighted to have a workaround and not have to restart the desktop every couple of days.

If the pixmaps were still known by the server, one could run around and wipe all pixmaps that can no longer be allocated to a specific client (though this will likely cause false positives)

Otherwise the only way to prevent the leak is to disable systray icons for the problematic clients - or do not use plasma-desktop systray but some standalone trayer like ... eg. "trayer" (gtk+) or "stalonetray" (X11 only) or "tksystray" (tcl/tk)

Notice that it will be required to disable the "status notifier daemon" in "kcmshell4 kded" in order to at least make KDE/Qt applications use the fdo (and not the dbus) systray icons.

Alternatively upgrade to the fixed verson.

Thanks for the rundown! I found a PPA (unofficial) backport of KDE 4.11.2 to Ubuntu Precise. I'll try upgrading and hopefully the problem will be gone.