Bug 443239 - aggressive Xorg memory leak when desktop effects are enabled
aggressive Xorg memory leak when desktop effects are enabled
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-i810 (Show other bugs)
9
x86_64 Linux
low Severity high
: ---
: ---
Assigned To: Adam Jackson
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-04-19 12:49 EDT by Juha Heljoranta
Modified: 2009-07-14 13:36 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-07-14 13:36:40 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Xorg log with backtrace (21.84 KB, text/plain)
2008-04-19 12:49 EDT, Juha Heljoranta
no flags Details
Xorg.0.log.old: Existing errors found in hardware state (39.10 KB, text/plain)
2008-04-21 17:13 EDT, Juha Heljoranta
no flags Details

  None (edit)
Description Juha Heljoranta 2008-04-19 12:49:49 EDT
Description of problem:
When desktop effects are enabled Xorg leaks memory on normal desktop usage (e.g.
alt-tab)

Version-Release number of selected component (if applicable):
xorg-x11-drv-i810-2.2.1-20.fc9.x86_64
kernel-2.6.25-1.fc9.x86_64

How reproducible:
Enable desktop effects and hit alt-tab.

Steps to Reproduce:
1. Enable desktop effects
2. e.g. hit alt-tab
3. goto step 2.

Actual results:
Xorg rss grows on every alt-tab operation and will eventually crash X.

Expected results:
Xorg memory usage should remain roughly same.

Additional info:
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)
Comment 1 Juha Heljoranta 2008-04-19 12:49:49 EDT
Created attachment 303005 [details]
Xorg log with backtrace
Comment 2 Dave Airlie 2008-04-19 19:36:55 EDT
what version of mesa-libGL have you installed?

if its less than 28 please try 28 from koji.
Comment 3 Juha Heljoranta 2008-04-20 12:20:17 EDT
(In reply to comment #2)
> what version of mesa-libGL have you installed?
> if its less than 28 please try 28 from koji.

mesa-libGL-7.1-0.25.fc9.x86_64

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...
Comment 4 Juha Heljoranta 2008-04-21 17:10:20 EDT
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.
Comment 5 Juha Heljoranta 2008-04-21 17:13:06 EDT
Created attachment 303206 [details]
Xorg.0.log.old: Existing errors found in hardware state
Comment 6 Dave Airlie 2008-05-05 18:22:24 EDT
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.
Comment 7 Juha Heljoranta 2008-05-07 12:44:41 EDT
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
mesa-libGLU-7.1-0.29.fc9.x86_64
mesa-libGL-7.1-0.29.fc9.x86_64

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 :)
$ free
             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
Comment 8 Bug Zapper 2008-05-14 05:44:34 EDT
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 9 Enrico Scholz 2008-06-20 03:35:23 EDT
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).

kernel-2.6.25.6-55.fc9.x86_64
mesa-libGL-7.1-0.31.fc9.x86_64
xorg-x11-server-Xorg-1.4.99.902-3.20080612.fc9.x86_64
Comment 10 Enrico Scholz 2008-06-20 04:20:43 EDT
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.
Comment 11 Enrico Scholz 2008-06-23 05:56:44 EDT
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
Comment 12 Chris Snook 2008-06-25 02:37:22 EDT
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?
Comment 13 Chris Snook 2008-06-25 02:47:28 EDT
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
to this.
Comment 14 Enrico Scholz 2008-06-25 03:25:56 EDT
might be http://bugs.freedesktop.org/show_bug.cgi?id=16316
Comment 15 Ravikiran Rajagopal 2008-07-23 10:10:32 EDT
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?
Comment 16 Christof Kaelin 2008-12-04 15:34:09 EST
Still happens in F10 on my X61s thinkpad.
Comment 17 Bug Zapper 2009-06-09 20:17:20 EDT
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: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 18 Bug Zapper 2009-07-14 13:36:40 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.