Xorg memory leak on trusty

Bug #1272338 reported by Alan Pope 🍺🐧🐱 πŸ¦„
This bug affects 20 people
Affects Status Importance Assigned to Milestone
fglrx-driver (Ubuntu)
xserver-xorg-video-intel (Ubuntu)
Fix Released

Bug Description

After a few hours Xorg process was consuming a GB of RAM, after a day or so it was 2GB, now after 2 days it's over 4GB. I'd rather X wasn't eating all my RAM.

 1710 root 20 0 5270636 4.300g 277872 S 14.2 27.6 229:09.97 Xorg

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: xorg 1:7.7+1ubuntu7
ProcVersionSignature: Ubuntu 3.13.0-5.20-generic 3.13.0
Uname: Linux 3.13.0-5-generic x86_64

ApportVersion: 2.13.1-0ubuntu1
Architecture: amd64
CompizPlugins: [core,composite,opengl,compiztoolbox,decor,grid,imgpng,gnomecompat,scale,workarounds,mousepoll,regex,wall,move,place,vpswitch,resize,unitymtgrabhandles,snap,session,expo,ezoom,unityshell]
CompositorRunning: compiz
CompositorUnredirectDriverBlacklist: '(nouveau|Intel).*Mesa 8.0'
CompositorUnredirectFSW: true
CurrentDesktop: Unity
Date: Fri Jan 24 13:36:48 2014
DistUpgraded: 2014-01-20 08:54:25,315 DEBUG enabling apt cron job
DistroCodename: trusty
DistroVariant: ubuntu
EcryptfsInUse: Yes
ExtraDebuggingInterest: Yes
 Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller [8086:0126] (rev 09) (prog-if 00 [VGA controller])
   Subsystem: Lenovo Device [17aa:21da]
InstallationDate: Installed on 2012-06-29 (573 days ago)
InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Release amd64 (20120425)
MachineType: LENOVO 4287CTO
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.13.0-5-generic root=UUID=6088859e-4fc3-4ec8-903f-5b52cdc1d0eb ro quiet splash vt.handoff=7
SourcePackage: xorg
UpgradeStatus: Upgraded to trusty on 2014-01-20 (4 days ago)
dmi.bios.date: 12/05/2012
dmi.bios.vendor: LENOVO
dmi.bios.version: 8DET67WW (1.37 )
dmi.board.asset.tag: Not Available
dmi.board.name: 4287CTO
dmi.board.vendor: LENOVO
dmi.board.version: Not Available
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: Not Available
dmi.modalias: dmi:bvnLENOVO:bvr8DET67WW(1.37):bd12/05/2012:svnLENOVO:pn4287CTO:pvrThinkPadX220:rvnLENOVO:rn4287CTO:rvrNotAvailable:cvnLENOVO:ct10:cvrNotAvailable:
dmi.product.name: 4287CTO
dmi.product.version: ThinkPad X220
dmi.sys.vendor: LENOVO
version.compiz: compiz 1:0.9.10+13.10.20131011-0ubuntu1
version.ia32-libs: ia32-libs N/A
version.libdrm2: libdrm2 2.4.51-1
version.libgl1-mesa-dri: libgl1-mesa-dri 10.0.1-1ubuntu2
version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A
version.libgl1-mesa-glx: libgl1-mesa-glx 10.0.1-1ubuntu2
version.xserver-xorg-core: xserver-xorg-core 2:1.14.5-1ubuntu2
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.8.2-1ubuntu1
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:7.2.0-0ubuntu11
version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.907-0ubuntu1
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.10-1ubuntu1
xserver.bootTime: Wed Jan 22 12:54:42 2014
xserver.configfile: default

xserver.logfile: /var/log/Xorg.0.log
 product id 728
 vendor LGD
xserver.version: 2:1.14.5-1ubuntu2

Revision history for this message
Alan Pope 🍺🐧🐱 πŸ¦„ (popey) wrote :
Revision history for this message
Timo Aaltonen (tjaalton) wrote :

I think I'm seeing the same on IVB. Didn't have issues in saucy, but maybe the trusty kernel update 3.11->3.13 broke something, or the ddx bump .904->.907.

affects: xorg (Ubuntu) → xserver-xorg-video-intel (Ubuntu)
Revision history for this message
Alan Pope 🍺🐧🐱 πŸ¦„ (popey) wrote :

Output of xrestop attached.

Revision history for this message
Timo Aaltonen (tjaalton) wrote :

Yeah confirmed, after 10h Xorg takes >600MB. It was >4GB before reboot.

Changed in xserver-xorg-video-intel (Ubuntu):
importance: Undecided → High
status: New → Confirmed
Revision history for this message
Chris Wilson (ickle) wrote :

-intel? Any luck running with --enable-debug=memory and under valgrind?

Here after a few minutes it reports a steady leak from xserver/render/filter.c:SetPicturePictFilter()

diff --git a/render/picture.c b/render/picture.c
index 7da9310..92176fa 100644
--- a/render/picture.c
+++ b/render/picture.c
@@ -1441,6 +1441,7 @@ FreePicture(void *value, XID pid)

     if (--pPicture->refcnt == 0) {
+ free(pPicture->filter_params);

         if (pPicture->pSourcePict) {
             if (pPicture->pSourcePict->type != SourcePictTypeSolidFill)

Revision history for this message
Chris Wilson (ickle) wrote :

And please do paste /proc/`pidof X`/maps (or pmap `pidof X`).

Revision history for this message
Alan Pope 🍺🐧🐱 πŸ¦„ (popey) wrote :

Yeah, on intel.

 5591 root 20 0 9.797g 4.380g 192680 S 11.0 28.2 347:20.82 Xorg

Attached the maps.

Revision history for this message
Chris Wilson (ickle) wrote :

That suggests it is a malloc leak of consistently sized objects (i.e. we are leaking one particular type of fixed-size object). What is your usage pattern - what particularly aggravates the leak? Chromium, firefox, libreoffice, totem, etc?

Revision history for this message
Alan Pope 🍺🐧🐱 πŸ¦„ (popey) wrote :

I tend to have two chromium sessions open, one for personal, one for work. Typically they can have 20 tabs open each. They both have gmail always open. Personal also has G+, tweetdeck, drive and few non-dynamic pages. Most of my work pages are google docs or launchpad pages.

I may have spotify open.

Other than that I have a couple of terminals open and a few indicators. Now and then I'll open minecraft, but not that often, and that doesn't seem to correlate with this.

Nothing seems to aggravate it, but I do tend to have the same pages open all the time, so it could well be some js heavy page like G+ or tweetdeck?

Here's a process list in case I missed anything obvious.

Revision history for this message
Alan Pope 🍺🐧🐱 πŸ¦„ (popey) wrote :

Lets try that paste again *without* passwords (which have been changed) in the command lines. *ahem*.


Revision history for this message
Chris Wilson (ickle) wrote :

Now fixed:

commit bdbb928ea38977bd2784f454f35db2ac2c13c34c
Author: Chris Wilson <email address hidden>
Date: Fri Jan 31 15:03:43 2014 +0000

    sna: Actually reuse pixmap headers for ordinary pixmaps

    commit 3dbf17f00e200e864818b0b8ca762183cff9085f [2.99.907]
    Author: Chris Wilson <email address hidden>
    Date: Tue Dec 3 12:10:01 2013 +0000

        sna: Mark up an ordinary pixmap for reuse

    started to put the frequently allocated pixmaps into the object cache -
    but as those frequent allocations themselves did not use the cache, the
    cache kept growing.

    Bugzilla: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1272338
    Signed-off-by: Chris Wilson <email address hidden>

commit dfac4650e621055c5504c1bcf6df6449afa6d8d2
Author: Chris Wilson <email address hidden>
Date: Fri Jan 31 14:28:56 2014 +0000

    sna: Tidy up pixmap header allocations

    Refactor some more of the common code, and add some debug tracking.

    Signed-off-by: Chris Wilson <email address hidden>

Revision history for this message
Alan Pope 🍺🐧🐱 πŸ¦„ (popey) wrote :

Thanks Chris. Much appreciated.

Revision history for this message
Timo Aaltonen (tjaalton) wrote :

cool, I'll push an update immediately :)

Revision history for this message
Timo Aaltonen (tjaalton) wrote :

..or will wait for the rc instead, which should happen soon enough

Chris Wilson (ickle)
Changed in xserver-xorg-video-intel (Ubuntu):
status: Confirmed → Fix Committed
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package xserver-xorg-video-intel - 2:2.99.909-0ubuntu2

xserver-xorg-video-intel (2:2.99.909-0ubuntu2) trusty; urgency=medium

  * Refresh xmir patch.
 -- Maarten Lankhorst <email address hidden> Wed, 05 Feb 2014 14:33:04 +0000

Changed in xserver-xorg-video-intel (Ubuntu):
status: Fix Committed → Fix Released
Revision history for this message
devsk (funtoos) wrote :

Is this issue intel specific only? I am seeing it on Nvidia open source driver (nouveau). Does the same code apply there as well?

Revision history for this message
Chris Wilson (ickle) wrote :

There are leaks all over the place (the one most often reported is in one of the KDE systray applets). This particular bug was particularly to the Intel driver.

Revision history for this message
Nikola Nikolov (nikolov-tmw) wrote :

I know this specific bug was fixed, but I just wanted to say that I just installed Ubuntu 14.04. My PC has been running for over 9 hours for now and Xorg has not been using more than 200 MB RAM(whereas before the update, the memory consumption would keep drastically increasing over time). I can now finally run 2 separate Chrome windows(usually 2 different user sessions with multiple tabs open), without my computer freezing for over 10 minutes sometimes.

Revision history for this message
Adam Porter (alphapapa) wrote :

Chris, which KDE systray applet were you referring to? I'd like to know, in case it's one I have loaded. :)

Revision history for this message
Chris Wilson (ickle) wrote :

Not something I used, but the report was that it was leaking a pixmap every second - probably something like a clock.

Revision history for this message
Knowledge (dark-knowledge-lnx) wrote :

I have that problem too, Xorg consumes about 2GB of ram when using Firefox 7 or more pages open. with Maxthon on youtube or facebook, game occurs when using wine, I attached a screenshot.

Characteristics; Kubuntu 14.04 64bits, 3.13.0-29-generic, FX-6300 3.5Ghz, 4GB 1333Mhz, Nvidia GT440 1024Mb GDDR5 with proprietary drivers 337.25, no desktop visual effects

PD: sorry for my english....


Revision history for this message
Knowledge (dark-knowledge-lnx) wrote :

surfing the web, xorg increases RAM consumption in minutes not hours or days things to the point of collapsing the system


Revision history for this message
Stephen Venter (stephen-venter) wrote :

Having the same issue myself.

Xorg process gradually consumes more and more RAM over time until the desktop becomes unusable and either crashes, or needs to be rebooted to get going again.

== In my case below, PID 2012 is currently up to 2.1GB of RAM again.

root@host:~# free -m
             total used free shared buffers cached
Mem: 16039 15843 195 40 397 9416
-/+ buffers/cache: 6029 10010
Swap: 11585 3 11582

root@host:~# top -p 2012
top - 12:28:54 up 20:49, 5 users, load average: 2.61, 2.53, 2.57
Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie
%Cpu(s): 2.8 us, 1.8 sy, 0.0 ni, 82.5 id, 12.6 wa, 0.3 hi, 0.0 si, 0.0 st
KiB Mem: 16424276 total, 16235752 used, 188524 free, 408120 buffers
KiB Swap: 11863964 total, 3544 used, 11860420 free. 9652088 cached Mem

 2012 root 20 0 2572068 2.062g 205736 S 3.7 13.2 167:01.86 Xorg

root@host:~# ps -lf 2012
4 S root 2012 1930 13 80 0 - 641118 poll_s Aug12 tty7 166:31 /usr/bin/X -core :0 -seat seat0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch

root@host:~# ps -o pid=,args=,rss=,size=,vsize= 2012
 2012 /usr/bin/X -core :0 -seat s 2169192 1961620 2579280

root@host:~# uname -a
Linux host 3.13.0-30-generic #55-Ubuntu SMP Fri Jul 4 21:40:53 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

root@host:~# dpkg-query -l "*xorg*"
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
ii xorg 1:7.7+1ubuntu8 amd64 X.Org X Window System
ii xserver-xorg 1:7.7+1ubuntu8 amd64 X.Org X server
ii xserver-xorg-core 2:1.15.1-0ubuntu2 amd64 Xorg X server - core server

Revision history for this message
Prasanna Kannappan (prarobo) wrote :

I am also having problems with XOrg. Memory consumption goes over 2 Gb in a day of system uptime. Firefox is the primary application that is running most of the time.

I am running ubuntu 12.04 . This problem started occuring before a month or two. I suspect one of the updates broke something. I am using an ATI/AMD Graphics card.

Revision history for this message
Timothy J. Holloway (leather-turtle) wrote :

I've had problems with Ubuntu 14.10 then 14.04.1 LTS then Linux Mint 17 and now Linux Mint Debian Edition. I managed to get the system monitor app up and found mate-settings-daemon was taking up the most memory and I couldn't kill the process. 1.8GB or more of my 2GB was taken up and eventually the two cores of my CPU started making sine and cosine waves in the system resources tab. I had to reboot again on my new installation. I had hoped whatever the problem was, it had been corrected by the fresh installation.

Revision history for this message
Erik Walthinsen (omega-omegacs) wrote :

Experiencing this on Xubuntu 14.10 with the ATI proprietary driver with Radeon 270X 2GB. Right now the X server is over 6GB:

root 3444 10.6 44.3 6303840 5457648 tty7 Ss+ Mar14 238:46 /usr/bin/X -core :0 -seat seat0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch

Running Firefox, Thunderbird, plenty of terminals, and things like Cadsoft Eagle (5.12), Saleae Logic (1.1.18), LibreOffice, Evince, etc. Killed *ALL* of them and practically no change in X usage.

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in fglrx-driver (Ubuntu):
status: New → Confirmed
Revision history for this message
Mike Butash (michael-butash) wrote :

I'm getting this now in kde after upgrading 14.04 kernel to 3.16 and the beta fglrx drivers to run it. Not sure if also at the time changing the desktop effects opengl render modes affected this (compositing==ogl3.1, qt graphics==native, scaling==accurate, vsync==auto). Took about 8 hours to climb to consuming 28gb of ram. :\

$ xrandr
Screen 0: minimum 320 x 200, current 9600 x 1200, maximum 16384 x 16384
(5x 1920x1200 displays in eyefinity)

$ plasma-desktop -v
Qt: 4.8.6
KDE Development Platform: 4.13.3
Plasma Desktop Shell: 4.11.11

$ uname -a
Linux host 3.16.7-031607-generic #201412010535 SMP Mon Dec 1 10:36:33 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

$ sudo dpkg -l | grep fglrx
ii fglrx-amdcccle-updates 2:15.200-0ubuntu0.3 amd64 Catalyst Control Center for the AMD graphics accelerators
rc fglrx-core 2:15.200-0ubuntu0.3 amd64 Minimal video driver for the AMD graphics accelerators
ii fglrx-updates 2:15.200-0ubuntu0.3 amd64 Video driver for the AMD graphics accelerators
ii fglrx-updates-core 2:15.200-0ubuntu0.3 amd64 Minimal video driver for the AMD graphics accelerators
ii xvba-va-driver 0.7.8-1ubuntu3 amd64 XvBA-based backend for VA API (AMD fglrx implementation)

Revision history for this message
Mike Butash (michael-butash) wrote :

Oddly I can sit here and click between windows, changing the highlighting/focus, and watch memory bump up a 5-10mb each time, and NOT get reclaimed. Toggling compositing on and off does not relinquish the memory, I wonder if disabling the compositing layer will all together, but seems related to the desktop effects on windows.

Revision history for this message
EvgenijM86 (evgenij1) wrote :

I can confirm this bug on ubuntu 14.04. In my case I was playing a game in wine - Littlewitch Romanesque - and after 3-5 hours Xorg process was eating 4 GB RAM (normally it uses 200-400 mb). I use proprietary driver from fglrx-updates.

Revision history for this message
solax (solax76) wrote :

I have this bug with all distros I have installed, all based on ubuntu 14.04 (standard ubuntu, ubuntu with gnome, kubuntu, xubuntu and linux mint with cinnamon).
I use the nvidia driver and I have noticed that all these distros have the same behaviour: xorg and the wm process are both hungry of memory. The only exception is xfce that seems to be less affected (xorg process leaks memory also with xfce, only the wm process is not eating too much ram).

I have also noticed that other distros, not ubuntu based, have similar issues and with different graphic drivers. I suspect that the problem is relevant to some generic linux graphic library and not to a specific graphic driver.

Revision history for this message
Andreas Ritter (eddie8) wrote :

Also affected on this bug. Is there anything you can do, any command you can type or something like that to "flush" the memory xorg uses? Or is the only available workaround to restart xorg?

Revision history for this message
Chris Wilson (ickle) wrote :

Not all memory leaks are the same. The original bug here was a definite bug in one particular driver. Since then this has been falsely duplicated to a bug in the binary fglrx and also for the pixmap leaks in plasma. Please always open a bug for yourself, and for memory leak queries in addition to the usual logs (like Xorg.0.log) include /proc/`pidof Xorg`/status and the output of xresetop.

Revision history for this message
bmaupin (bmaupin) wrote :

See here for the same bug for the fglrx driver:

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers