Bug 248105 - plasma causes Xorg to use large amounts of memory
Summary: plasma causes Xorg to use large amounts of memory
Status: RESOLVED FIXED
Alias: None
Product: plasma4
Classification: Plasma
Component: general (show other bugs)
Version: 4.8.4
Platform: Ubuntu Linux
: NOR normal
Target Milestone: ---
Assignee: Plasma Bugs List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-08-17 02:18 UTC by Jesse Milette
Modified: 2013-08-03 09:10 UTC (History)
9 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 Jesse Milette 2010-08-17 02:18:07 UTC
Version:           unspecified (using KDE 4.5.0) 
OS:                Linux

I have noticed that over time Xorg grows in memory size; becoming absurdly bloated -- sometimes using up to 700Mb in ram.  As soon as I kill plasma-desktop the memory drops back down to the normal 230Mb.  The memory leak (i think that is what it is called) does not occur with compositing suspended -- only with it enabled.  I think that blur is doing it (this problem was not around in 4.4) but have not tried disabling it yet.

Reproducible: Didn't try

Steps to Reproduce:
enable compositing, use plasma

Actual Results:  
Xorg memory will become huge -- up to 700mb.

Expected Results:  
Xorg should never use that much ram.

OS: Linux (i686) release 2.6.32-24-generic
Compiler: cc
Comment 1 Juan Garcia 2010-08-17 21:24:36 UTC
I can confirm this bug.
I use Kubuntu 10.4 64bits updated to date and with KDE 4.5 SC from the Kubuntu backport repositories (also updated to date).

It can be reproduced every time. The Xorg memory usage starts under 100 Mbytes, but after a 8 hours it used 156MB and 200MB of shared memory (taken from KDE System Monitor). But the memory usage still grows, it seems like a proper memory leak somewhere.

Compositing is enabled. "Blur" effect is OFF. I have seen in some forums the "Blur" effect can be related to this problem. But I have the same problem even it is disabled.

Jesse, do you have the "Blur" effect on?
Comment 2 Jesse Milette 2010-08-18 00:19:28 UTC
workaround:
add the following lines to /etc/security/limits.conf:

root soft data 30000000
root hard data 60000000

Xorg wont use more then 100mb of ram; so swapping either.  Got the workaround off of ubuntu-forums.
Comment 3 Juan Garcia 2010-08-29 19:49:46 UTC
After updating Kubuntu 10.04 with the latest updates I cannot see this problem anymore.
I cannot tell which of the updates helped.
I can only tell I cannot see this issue since about two weeks ago.
Comment 4 Jesse Milette 2010-08-30 14:45:36 UTC
There was a QT update; I am keeping an eye on Xorg, it does not seem to be using the same amount of memory though.
Comment 5 Tamran 2010-08-30 21:37:46 UTC
I would like to also confirm that a large amount of memory is used after Jesse's workaround, but it indeed is at least a little better.  I am using Kubuntu 10.04 with the KDE 4.5 backport.  After just sitting idle for the weekend I was up to 250MB of ram for Xorg.

Juan, are you using the 4.5 backport (ppa:kubuntu-ppa/backports) or straight 10.04?  I ask because it may be possible to narrow it down to one of (or a combination of) the backport updates.
Comment 6 Juan Garcia 2010-08-31 20:37:56 UTC
Tamran, I also use Kubuntu 10.04 with the KDE 4.5 backport.

Yes, I recall there was a couple of QT packages updated, but still they are at Beta level. QT 4.7 release candidate has been released las week but it has not hit yet the repositories.
Comment 7 Beat Wolf 2010-09-02 11:49:49 UTC
what gpu driver do you use?

i had that problem with the nvidia binary driver. switching to nouveau solved the problem (and improved overall plasma speed).
Comment 8 Jesse Milette 2010-09-02 12:45:07 UTC
I am using the nvidia driver (geforce 8600M); however there is no way i am switching to nouveau -- I want 3d acceleration ;)
Comment 9 Beat Wolf 2010-09-02 12:50:18 UTC
but if you could do it just for a test, that might be interesting.
Comment 10 Juan Garcia 2010-09-02 20:14:37 UTC
I am using the AMD Catalyst drivers 1.8 64 bits.
Is anybody using also 64 bits?
Comment 11 Tamran 2010-09-02 20:18:47 UTC
Juan, I am using Nvidia binary drivers (geforce 7100) and am using 64bits.
Comment 12 Jesse Milette 2011-01-08 16:29:44 UTC
This is no longer a problem for me, I switched to raster rendering and one of the updates fixed it.
Comment 13 Tom 2011-04-13 03:58:25 UTC
*** This bug has been confirmed by popular vote. ***
Comment 14 Thijs 2012-05-31 08:02:51 UTC
On 4.8.3 with Intel graphics and opengl randering, X.org wants 27MB of memory, and plasma (the fatttest process of them all) wants 120MB. Could probably slim that down even further. Leaving my pc on for weeks does not pose any problems anymore. Does anyone still observe real memory leaks (related to plasma and X) beyond ,say, 300MB? If not, I think this one can be closed.
Comment 15 Marek Zukal 2012-06-19 15:33:54 UTC
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                 
 5297 zippy     20   0 1665m 209m  36m S  0.0  5.3  23:09.85 plasma-desktop                                                                                      
 5101 root      20   0  384m 187m  59m S  0.0  4.7  74:54.70 X

So, it is more than 300 MB after 2 days of uptime with a few sleeps... I still think it is a lot...
kde-workspace-4.8.4-1.fc17.x86_64
Comment 16 Luke-Jr 2012-12-12 18:58:46 UTC
I see a lot of leaking over time withOUT compositing - maybe I should open another bug?
Plasma/KDE 4.8.5
Qt 4.8.2
X.org server 1.12.2
xf86-video-intel 2.20.12

This leak was so bad after 70 days that any notification (even Psi merely blinking the system tray icon, or a new window being added to the taskbar) substantially slowed down the whole system. When I finally kquitapp plasma-desktop, the entire X server locked up for about 5 minutes as it swapped in the resources it was freeing. ps's "size" reports the same memory for X before and after (2.3 GB), and I didn't run xrestop to get more granular details.
Comment 17 Andreas Hartmetz 2013-07-02 17:32:16 UTC
It looks like the original bug was fixed at some point and the more recent report is a duplicate of the now fixed bug 314919.