Bug 454117 - X server+KDE desktop effects leaks a lot of memory
X server+KDE desktop effects leaks a lot of memory
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-ati (Show other bugs)
9
x86_64 Linux
low Severity high
: ---
: ---
Assigned To: Dave Airlie
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-07-04 15:53 EDT by Carl Roth
Modified: 2009-07-14 13:32 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-07-14 13:32:04 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)
X server configuration file (884 bytes, text/plain)
2008-07-04 15:55 EDT, Carl Roth
no flags Details
X server startup log (44.85 KB, text/plain)
2008-07-04 15:56 EDT, Carl Roth
no flags Details

  None (edit)
Description Carl Roth 2008-07-04 15:53:41 EDT
Description of problem:

I installed the new xorg-x11-drv-ati driver along with an updated Mesa and it
appears to have some pretty bad memory leaks when running AIGLX and KDE desktop
effects.

I ran the system for a few days until I noticed that my swap was filling up... 
Steady use of GLX eye candy and youtube videos rocketed my X server usage to
over 9GiB.

For a smaller, more reproducible example: when I switch between desktops (forget
the name of the effect, but it creates a panning effect) it leaks 10-20KiB each
switch.

Version-Release number of selected component (if applicable):

xorg-x11-drv-ati-6.8.0-18.fc9.x86_64
mesa-libGL-7.1-0.35.fc9.x86_64

My system is running an ATI X1800 card.

How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 Carl Roth 2008-07-04 15:55:15 EDT
Created attachment 311055 [details]
X server configuration file
Comment 2 Carl Roth 2008-07-04 15:56:31 EDT
Created attachment 311056 [details]
X server startup log
Comment 3 Ravikiran Rajagopal 2008-07-11 11:44:21 EDT
I have the same problem as well. I can reproduce it in F9 x86_64 with all 
packages up-to-date, along with latest F9 mesa, libdrm, xorg-x11-server, 
xorg-x11-drv-ati and kernel from koji.

I modified the xorg-x11-server package to insert a call to mtrace and 
recompiled mesa and xorg-x11-server with --enable-debug; I see the leaks but I 
do not get function/line information upon processing the output with mtrace 
from glibc-utils. Running Xorg under valgrind is problematic: Xorg needs to 
not be setuid, and Xorg does not exit until I kill it with a SIGHUP. Valgrind 
does not report huge memory leaks (only on the order of a few kb) even though 
Xorg seems to eat the memory according to 'top'. Perhaps killing the valgrind 
process to stop Xorg is not the best idea, but is there another alternative?

I am using X1650 Pro. The Device section has only two extra options setting 
PanelSize to 1680x1050 and AccelMethod to EXA. The rest of xorg.conf is 
trivial; no modules are loaded other than the default. I can reproduce this 
bug with Radeon Xpress 200M as well. I do not have access to any other 
hardware.

I thought that this may be related to bug 443239 (and bug 16316 at fd.o), but 
my valgrind log does not show the same leaks that are shown there. I do have 
the updated pixman as well.

I'd be happy to provide any information that may help solve this problem.
Comment 4 Ravikiran Rajagopal 2008-07-15 18:55:53 EDT
Detailed investigation of the memory leak yielded two potential culprits:
(1) Memory leak when switching desktops (more on this later)
(2) Smaller but more continuous leaks whose cause I have not isolated yet.

The main packages of interest:
  xorg-x11-server-Xorg-1.4.99.905-2.20080702.f9.x86_64
  kdelibs-4.0.98-2.fc9.x86_64
  kdebase-4.0.98-2.fc9.x86_64
  mesa-libGL-7.1-0.37.f9.x86_64
  Using X1650 Pro on an x86_64 machine
All of the above were recompiled locally with debug information. The kde* RPMS
came from kde-redhat packaged by Rex Dieter. The bug under discussion is 
present
with the current stable F9 npackages as well.

To isolate the first leak (identified via mtrace), I used a KDE session with 
one
konsole window on one virtual desktop. Then, I repeatedly switched from that 
desktop
to an empty one and back again. Looking through /proc/<pid of X>/smaps, I 
noticed
that at least 2217172 bytes were leaked during every switch (i.e., going to a 
different desktop and returning).

Attaching GDB to the X process, I observed the following memory allocations 
for each
switch back to the desktop containing the konsole window:

#0  Xalloc (amount=2217172) at utils.c:1326
#1  0x000000000042d251 in AllocatePixmap (pScreen=<value optimized out>, 
pixDataSize=-2217109) at pixmap.c:116
#2  0x00000000037a6453 in fbCreatePixmapBpp (pScreen=0x21d4d4, width=667, 
height=<value optimized out>, depth=32,
    bpp=32, usage_hint=2) at fbpixmap.c:53
#3  0x00000000015013d7 in exaCreatePixmap (pScreen=0x1998bb0, w=667, h=831, 
depth=32, usage_hint=2) at exa.c:286
#4  0x00000000004fbc2e in compNewPixmap (pWin=0x1bef0b0, x=0, y=0, w=667, 
h=831) at compalloc.c:468
#5  0x00000000004fbff5 in compAllocPixmap (pWin=0x1bef0b0) at compalloc.c:548
#6  0x00000000004fb856 in compRealizeWindow (pWin=0x1bef0b0) at 
compwindow.c:242
#7  0x000000000043649b in RealizeTree (pWin=0x1bef0b0) at window.c:2684
#8  0x0000000000436823 in MapWindow (pWin=0x1bef0b0, client=0x1a67950) at 
window.c:2798
#9  0x0000000000448a06 in ProcMapWindow (client=0x1a67950) at dispatch.c:695
#10 0x0000000000449284 in Dispatch () at dispatch.c:454
#11 0x000000000042cdad in main (argc=7, argv=0x7fff8941f1b8, envp=<value 
optimized out>) at main.c:445
--> Note: Value returned from Xalloc is (void *) 0x7f0e5b937200

#0  Xalloc (amount=2217172) at utils.c:1326
#1  0x000000000042d251 in AllocatePixmap (pScreen=<value optimized out>, 
pixDataSize=-2217109) at pixmap.c:116
#2  0x00000000037a6453 in fbCreatePixmapBpp (pScreen=0x21d4d4, width=667, 
height=<value optimized out>, depth=24,
    bpp=32, usage_hint=2) at fbpixmap.c:53
#3  0x00000000015013d7 in exaCreatePixmap (pScreen=0x1998bb0, w=667, h=831, 
depth=24, usage_hint=2) at exa.c:286
#4  0x00000000004fbc2e in compNewPixmap (pWin=0x234def0, x=0, y=0, w=667, 
h=831) at compalloc.c:468
#5  0x00000000004fbff5 in compAllocPixmap (pWin=0x234def0) at compalloc.c:548
#6  0x00000000004fb856 in compRealizeWindow (pWin=0x234def0) at 
compwindow.c:242
#7  0x000000000043649b in RealizeTree (pWin=0x1bef0b0) at window.c:2684
#8  0x0000000000436823 in MapWindow (pWin=0x1bef0b0, client=0x1a67950) at 
window.c:2798
#9  0x0000000000448a06 in ProcMapWindow (client=0x1a67950) at dispatch.c:695
#10 0x0000000000449284 in Dispatch () at dispatch.c:454
#11 0x000000000042cdad in main (argc=7, argv=0x7fff8941f1b8, envp=<value 
optimized out>) at main.c:445
--> Note: Value returned from Xalloc is (void *) 0x7f0e5bb546e0

Both of the backtraces above came from the same call to RealizeTree. Given 
that only
one window is present, it is suspicious that two pixmaps are allocated. So, I 
captured
the return value of Xalloc and checked to see whether Xfree is ever called 
with those
values. I did this by seeting breakpoints on Xfree conditioned on the pointer 
being
one of the values from Xalloc.

When moving away from the desktop with the konsole towards an empty desktop,
the following backtrace hits on Xfree, but ONLY for the second pointer 
obtained. The
first pointer is never passed back to Xfree (creating a leak). Here is the 
backtrace
for the second pointer's call to Xfree:

0  Xfree (ptr=0x7f0e5bb546e0) at utils.c:1457
#1  0x00000000037a63a2 in fbDestroyPixmap (pPixmap=0x7f0e5bb546e0) at 
fbpixmap.c:104
#2  0x000000000052a9cd in damageDestroyPixmap (pPixmap=0x7f0e5bb546e0) at 
damage.c:1680
#3  0x0000000000127e0d in XvDestroyPixmap (pPix=0x7f0e5bb546e0) at 
xvmain.c:381
#4  0x00000000004fb755 in compCheckRedirect (pWin=0x234def0) at 
compwindow.c:163
#5  0x00000000004fb7c6 in compUnrealizeWindow (pWin=0x234def0) at 
compwindow.c:259
#6  0x0000000000436f7a in UnrealizeTree (pWin=0x1bef0b0, fromConfigure=0) at 
window.c:2995
#7  0x0000000000437282 in UnmapWindow (pWin=0x1bef0b0, fromConfigure=0) at 
window.c:3056
#8  0x0000000000448965 in ProcUnmapWindow (client=0x1a67950) at dispatch.c:727
#9  0x0000000000449284 in Dispatch () at dispatch.c:454
#10 0x000000000042cdad in main (argc=7, argv=0x7fff8941f1b8, envp=<value 
optimized out>) at main.c:445

This pattern holds consistently for every switch of virtual desktops. Similar 
pattern holds for
minimizing and restoring windows. However, in that case, some extra calls to 
Xalloc are made though
they do not leak.

Is there anything else I can provide?
Comment 5 Ravikiran Rajagopal 2008-07-21 15:13:06 EDT
Here's a simple (and a complete hack of a) patch to fix this memory leak:

--- glx/glxcmds.c.orig  2008-07-21 14:26:08.000000000 -0400
+++ glx/glxcmds.c       2008-07-21 14:30:54.000000000 -0400
@@ -1225,6 +1225,11 @@
 
     if (type == GLX_DRAWABLE_PIXMAP) {
        ((PixmapPtr) pGlxDraw->pDraw)->refcnt--;
+        /**** Major hack to get rid of pixmap since the id for the
+              pixmap is sometimes different from that of glxdrawable ***/
+        if (((PixmapPtr) pGlxDraw->pDraw)->refcnt == 0 ) {
+            xfree( (PixmapPtr) pGlxDraw->pDraw );
+        }
     }
 
     FreeResource(glxdrawable, FALSE);

The patch above is for xorg-x11-server. The fundamental problem is that in 
DoDestroyDrawable, a pixmap whose reference count goes to zero is not 
destroyed.
Comment 6 Kristian Høgsberg 2008-07-21 15:39:32 EDT
Committed upstream:

http://cgit.freedesktop.org/xorg/xserver/commit/?id=d5ae85b5b722821499d5796cf0973ecb6ec125f1

We'll merge it to the 1.5 branch and pull the fix when we rebase rawhide.
Comment 7 Jan ONDREJ 2008-07-23 03:33:21 EDT
Same problem for me, but I am using gnome+compiz-fusion. Without compiz there is
no problem. After starting compiz all my ram is slowly eated by Xorg process.
After aprox. 8 hours of working 1 GB free RAM is gone and half GB swap is used.

My arch is i386, my card is radeon 9200.

Problem started after upgrade to F9.
Comment 8 Bug Zapper 2009-06-09 21:55:25 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 9 Bug Zapper 2009-07-14 13:32:04 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.