Red Hat Bugzilla – Bug 443239
aggressive Xorg memory leak when desktop effects are enabled
Last modified: 2009-07-14 13:36:40 EDT
Description of problem:
When desktop effects are enabled Xorg leaks memory on normal desktop usage (e.g.
Version-Release number of selected component (if applicable):
Enable desktop effects and hit alt-tab.
Steps to Reproduce:
1. Enable desktop effects
2. e.g. hit alt-tab
3. goto step 2.
Xorg rss grows on every alt-tab operation and will eventually crash X.
Xorg memory usage should remain roughly same.
lspci | grep VGA
00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960
Integrated Graphics Controller (rev 03)
lspci -ns 00:02.0
00:02.0 0300: 8086:2a02 (rev 03)
Created attachment 303005 [details]
Xorg log with backtrace
what version of mesa-libGL have you installed?
if its less than 28 please try 28 from koji.
(In reply to comment #2)
> what version of mesa-libGL have you installed?
> if its less than 28 please try 28 from koji.
This is clean install of the Fedora-9-Preview-x86_64 + latest updates.
I'll test the 28 once the koji is fixed...
koji download-build --arch x86_64 mesa-7.1-0.28.fc9
URLGrabError: [Errno 14] HTTP Error 404: Not Found
Or is there another way to access the build?
http://koji.fedoraproject.org/koji/buildinfo?buildID=46557 gives also 404 for
the download links...
mesa-libGL-7.1-0.28.fc9.x86_64 *seems* to fix the desktop effects problem at
least partially. I cannot get X to crash easily.
By repeatedly opening and closing a new window while playing with desktop
effects leaks about few megabytes per closed window.
At some point (can take a long time) the X hangs it self. No stack trace to
Xorg.0.log or to /var/log/messages. I'll attach the Xorg.0.log.old since it has
some new details for some reason.
Created attachment 303206 [details]
Xorg.0.log.old: Existing errors found in hardware state
are you saying this is a lot better now or is still crashing on alt-tab?
need to decide if it still is a real blocker.
I cannot get Xorg to crash with desktop effects enabled. Although the Xorg
memory usage is quite high. System is stable after one hour of testing desktop
effects. Memory usage stops growing at certain point.
$ rpm -qa | grep mesa
Following memory usage is generated with default gnome desktop environment, ~10
gnome-terminals and by playing with desktop effects. Other programs that where
executed while testing are: top, ps and less. One could hope that Xorg uses
little less memory... But hey, at least it doesn't crash anymore :)
total used free shared buffers cached
Mem: 2052764 2032520 20244 0 4216 176900
-/+ buffers/cache: 1851404 201360
Swap: 2031608 31364 2000244
$ ps -vp 7908
Warning: bad syntax, perhaps a bogus '-'? See /usr/share/doc/procps-3.2.7/FAQ
PID TTY STAT TIME MAJFL TRS DRS RSS %MEM COMMAND
7908 tty9 Ss+ 7:21 171 1718 1808897 1371756 66.8 /usr/bin/Xorg :0
-br -verbose -auth /var/run/gdm/auth-cookie-XXS7IWAU-for-gdm -nolisten tcp
$ xrandr | grep current
Screen 0: minimum 320 x 200, current 1440 x 900, maximum 1440 x 1440
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
X memory leak exists here ditto; but with xfce4 env and sawfish wm. E.g. I see
root 3064 0.7 19.3 1821196 772940 tty7 Ss+ May27 253:01 \_ /usr/bin/X
-nolisten tcp :0 vt7 -auth /var/run/xauth/A:0-dCk
root 2705 2.6 18.6 959900 380332 tty7 Ss+ Jun19 26:29 \_ /usr/bin/X
-br -nolisten tcp :0 vt7 -auth /var/run/xauth/A:0-Y9U8U5
on two different machines (but both with Intel graphics):
00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated
Graphics Controller (rev 0c)
00:02.1 Display controller: Intel Corporation 82Q963/Q965 Integrated Graphics
Controller (rev 02)
Latter machine was restarted yesterday due to the high X memory usage
(it was 5GB VSZ/1GB RSS).
opening new PDFs with okular (kdegraphics-4.0.5-1.fc9.x86_64) seems to
trigger the leak; after opening two pdfs I am now at
root 2705 2.5 24.1 1065440 491500 tty7 Ss+ Jun19 26:58 \_ /usr/bin/X
-br -nolisten tcp :0 vt7 -auth /var/run/xauth/A:0-Y9U8U5
Closing okular does not lower these numbers; reopening same PDF does
not affect the memory usage either. It seems that some memory is used
as cache which is increased on demand but never be shrinked.
Now, I am nearly at 4GiB VSZ
root 2705 3.6 28.0 3894804 570636 tty7 Ss+ Jun19 199:47 \_ /usr/bin/X -br -nolisten tcp :0 vt7 -auth /var/run/xauth/A:0-Y9U8U5
but 'xrestop' reports only a minimal resource usage:
| xrestop - Display: localhost:0
| Monitoring 46 clients. XErrors: 2
| Pixmaps: 435K total, Other: 193K total, All: 629K total
| res-base Wins GCs Fnts Pxms Misc Pxm mem Other Total PID Identifier
| 1600000 91 80 4 28 1469 223K 42K 266K ? Sawfish
| 1400000 23 20 2 28 445 101K 13K 114K ? <unknown>
| 1800000 189 138 1 90 127 85K 11K 97K 1500 Bug 443239: aggressive Xorg memory leak when desktop effects are enabled - Mozilla Firefox
| 3a00000 12 31 16 8 7 9K 17K 26K ? XEmacs: - /home/ensc/.mozilla/firefox/default.356/itsalltext/bugzilla.redhat.com.201j311h1d.txt (bugzilla.redhat.c
| 0e00000 2 2 1 0 562 0B 14K 14K ? screensaver
| 3400000 34 3 1 15 14 6K 2K 8K 2973 kio_uiserver
Me too, using KDE, konsole, firefox, and pidgin on a Thinkpad T60 with Intel 950
graphics, all packages updated (F9, not rawhide) as of this evening.
Curiously, after disabling desktop effects and restarting X (but not the
machine) there's much more free memory, but I still get the "background not
redrawing" effect, and in /proc/slabinfo I have this bewildering entry:
numa_policy 299058 299370 24 170 1 : tunables 0 0 0 :
slabdata 1761 1761 0
Maybe we're leaking a numa_policy struct in the kernel as well for each of these
shared mappings we're leaking in userspace?
Nevermind, it looks like the kernel needs 300k numa_policy objects just to boot
and start KDE. That's arguably an efficiency bug in the kernel, but not related
might be http://bugs.freedesktop.org/show_bug.cgi?id=16316
Could one of you please try the fix from bug 454117 (not my patch but the
improved one from krh) and see whether that works for you?
Still happens in F10 on my X61s thinkpad.
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '9'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 9's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 9 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
The process we are following is described here:
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.
Thank you for reporting this bug and we are sorry it could not be fixed.