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:
Created attachment 311055 [details] X server configuration file
Created attachment 311056 [details] X server startup log
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.
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?
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.
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.
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.
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
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.