[Jaunty][UXA]compiz.real memory leak

[Ivan Stetsenko]

At some point I've noticed that process compiz.real started to use enormous amount of memory. After two days it uses about 500 mb of RAM and 2 gb(!) of swap. And I'm using UXA, btw.

ii compiz 1:0.7.9+git20090211-0ubuntu1
ii xserver-xorg-video-intel 2:2.6.1-1ubuntu2
ii xserver-xorg-core 2:1.5.99.902-0ubuntu6

[Bart Kroon (tarmack)]

As discussed on the forum in this thread: http://ubuntuforums.org/showthread.php?s=d0ff5aae247ab70c9a4cd20b123a281e&t=1071218
I also believe its a bug with uxa acceleration on the intel x.org driver. I come to this conclusion because I see the same problem with KDE4.2 using compositing. It even makes my X server crash on a system with 2.5GB of ram. This started after I switched to uxa acceleration, now switching back to exa will report in a few days.

[Shuang-he (shuang-he)]

System Environment:
--------------------------
Libdrm: (master)2e2e8575b1ed4703653a72ac2b60b75316c388d7
Mesa: (mesa_7_4_branch)119360cccdd49475eed67dde6344bf9f9904bc1b
Xserver: (server-1.6-branch)60c161545af80eb78eb790a05bde79409dfdf16e
Xf86_video_intel:(2.7)490cb578aef761e3fdd0a559bec36cdab96e6b2a
Kernel: (for-airlied)dc529a4fe1ae4667c819437a94185e8581e1e680

Bug detailed description:
-------------------------
with compiz enabled, keeping resizing glxgears window would make used memory keep increasing (reported from 'top'). At some point, system will start to use swap memory, and just a bit moment, X will stop responding, and complains about:

Execbuffer fails to pin. Estimate: 8470528. Actual: 10534912. Available: 240881664
Execbuffer fails to pin. Estimate: 8470528. Actual: 10534912. Available: 240881664
Execbuffer fails to pin. Estimate: 8470528. Actual: 10534912. Available: 240881664
Execbuffer fails to pin. Estimate: 8470528. Actual: 10534912. Available: 240881664
Execbuffer fails to pin. Estimate: 8470528. Actual: 10534912. Available: 240881664
Execbuffer fails to pin. Estimate: 8470528. Actual: 10534912. Available: 240881664
Execbuffer fails to pin. Estimate: 8470528. Actual: 10534912. Available: 240881664
Execbuffer fails to pin. Estimate: 8470528. Actual: 10534912. Available: 240881664
Execbuffer fails to pin. Estimate: 8470528. Actual: 10534912. Available: 240881664

reproduce steps:
------------------------
1. startx
2. enable compiz
3. run glxgears
4. keep resizing glxgears

[Shuang-he (shuang-he)]

Created an attachment (id=23950)
xorg log

[Shuang-he (shuang-he)]

Created an attachment (id=23951)
dmesg after X hang

[Gordon Jin (gordon-jin)]

This is for moblin bug 1218.

[Shuang-he (shuang-he)]

As what I heard from Moblin, Moblin is experiencing more serious memory leak (they got this issue just for resizing glxgears for a few minutes, though I got it for about half an hour), and is impacting them a lot.
So please take this one as highest priority.

[Jesse Barnes (jbarnes-virtuousgeek)]

Looks like the DRI2 buffers aren't getting freed. At resize time we get several calls:
indirect create drawable
DRI2CreateDrawable: new drawable, size 328x81
DRI2GetBuffers, buffers = (nil), size 328x81, count 0
indirect drawable destroy 308x86
indirect drawable destroy 300x300
indirect create drawable
DRI2CreateDrawable: new drawable, size 622x498
DRI2GetBuffers, buffers = (nil), size 622x498, count 0
indirect create drawable
DRI2CreateDrawable: new drawable, size 650x81
indirect drawable destroy 328x81
DRI2GetBuffers, buffers = (nil), size 650x81, count 0

But the __glXDRIdrawableDestroy doesn't end up calling the DRI2 destroy function because pDraw is NULL (seems like it shouldn't be). I'm tracing it more now to see if I can find the root cause.

[Jesse Barnes (jbarnes-virtuousgeek)]

Created an attachment (id=24216)
don't clear pDraw until after unref

Can you give this server patch a try? I'm not too familiar with the GLX internals, but it looks like we're clearing pDraw of the GLX drawable too soon, which prevents the DRI2 destroy drawable routine from actually freeing the associated DRI2 buffers... Seems to do the right thing in my light testing, but I didn't do a 30 min test like you did. :)

[Shuang-he (shuang-he)]

(In reply to comment #6)
> Created an attachment (id=24216) [details]
> don't clear pDraw until after unref
>
> Can you give this server patch a try? I'm not too familiar with the GLX
> internals, but it looks like we're clearing pDraw of the GLX drawable too soon,
> which prevents the DRI2 destroy drawable routine from actually freeing the
> associated DRI2 buffers... Seems to do the right thing in my light testing,
> but I didn't do a 30 min test like you did. :)
>

This patch works for me. Thanks Jesse

[Shuang-he (shuang-he)]

(In reply to comment #7)
> (In reply to comment #6)
> > Created an attachment (id=24216) [details] [details]
> > don't clear pDraw until after unref
> >
> > Can you give this server patch a try? I'm not too familiar with the GLX
> > internals, but it looks like we're clearing pDraw of the GLX drawable too soon,
> > which prevents the DRI2 destroy drawable routine from actually freeing the
> > associated DRI2 buffers... Seems to do the right thing in my light testing,
> > but I didn't do a 30 min test like you did. :)
> >
> This patch works for me. Thanks Jesse

Oh, this patch introduce new issue. just resizing it a bit, may crash X
Here's the backtrace:
(gdb) bt
#0 0xb7fd5424 in __kernel_vsyscall ()
#1 0x03155660 in raise () from /lib/libc.so.6
#2 0x03157028 in abort () from /lib/libc.so.6
#3 0x031925bd in __libc_message () from /lib/libc.so.6
#4 0x031987e4 in malloc_printerr () from /lib/libc.so.6
#5 0x0319c441 in _int_realloc () from /lib/libc.so.6
#6 0x0319d176 in realloc () from /lib/libc.so.6
#7 0x08131002 in Xrealloc (ptr=0x6, amount=0) at utils.c:1133
#8 0x0806d10b in dixAllocatePrivate (privates=0x91487c8, key=0xb7e90a3c)
    at privates.c:129
#9 0x0806d1cc in dixSetPrivate (privates=0x91487c8, key=0xb7e90a3c, val=0x0)
    at privates.c:193
#10 0xb7e8eca1 in DRI2DestroyDrawable (pDraw=0x91487b0) at dri2.c:218
#11 0xb7eee668 in __glXDRIdrawableDestroy (drawable=0x9205ff0) at glxdri2.c:108
#12 0xb7ee49bb in __glXUnrefDrawable (glxPriv=0x9205ff0) at glxutil.c:58
#13 0xb7ee3183 in DrawableGone (glxPriv=0x9205ff0, xid=12583326)
    at glxext.c:131
#14 0x0806efdc in FreeResource (id=12583326, skipDeleteFuncType=0)
    at resource.c:561
#15 0xb7edffa6 in DoDestroyDrawable (cl=<value optimized out>,
    glxdrawable=12583326, type=1) at glxcmds.c:1225
#16 0xb7ee340a in __glXDispatch (client=0x8d79db8) at glxext.c:523
#17 0x080874cf in Dispatch () at dispatch.c:437
---Type <return> to continue, or q <return> to quit---
#18 0x0806c69d in main (argc=2, argv=0xbf9d2754, envp=Cannot access memory at address 0xbde
) at main.c:397

[Jesse Barnes (jbarnes-virtuousgeek)]

Created an attachment (id=24296)
fixup GLX drawable management

I think this is a more complete fix; I'm still waiting on review from some X people.

[Mingming Ren (portis25)]

You can try this patch for xserver,
http://bugs.freedesktop.org/attachment.cgi?id=24296
which is mentioned in the following bug report:
http://bugs.freedesktop.org/show_bug.cgi?id=20704,

It works for me, although it seems still have file descriptor leakage.

[Jesse Barnes (jbarnes-virtuousgeek)]

Created an attachment (id=24328)
leak fix

Ok hope this is the last one. Please test.

[drseergio (drseergio)]

The last leak fix does not work for me...

Backtrace:
0: /usr/bin/X(xorg_backtrace+0x3c) [0x81347dc]
1: /usr/bin/X(xf86SigHandler+0x52) [0x80d4fe2]
2: [0xb8071400]
3: /usr/bin/X(dixSetPrivate+0x5c) [0x8070a8c]
4: /usr/lib/xorg/modules/extensions//libdri2.so(DRI2DestroyDrawable+0x9f) [0xb7$
5: /usr/lib/xorg/modules/extensions//libglx.so [0xb7a65fd8]
6: /usr/lib/xorg/modules/extensions//libglx.so(__glXUnrefDrawable+0x47) [0xb7a5$
7: /usr/lib/xorg/modules/extensions//libglx.so [0xb7a5a630]
8: /usr/bin/X(FreeResource+0x114) [0x8072a94]
9: /usr/lib/xorg/modules/extensions//libglx.so [0xb7a57404]
10: /usr/lib/xorg/modules/extensions//libglx.so [0xb7a5a8c2]
11: /usr/bin/X(Dispatch+0x34f) [0x808b53f]
12: /usr/bin/X(main+0x3bd) [0x806ff8d]
13: /lib/libc.so.6(__libc_start_main+0xe1) [0xb7b9b621]
14: /usr/bin/X [0x806f411]

Fatal server error:
Caught signal 11. Server aborting

[Shuang-he (shuang-he)]

(In reply to comment #10)
> Created an attachment (id=24328) [details]
> leak fix
>
> Ok hope this is the last one. Please test.
>

Get same backtrace as in Comment #8

[Shuang-he (shuang-he)]

(In reply to comment #12)
> (In reply to comment #10)
> > Created an attachment (id=24328) [details] [details]
> > leak fix
> >
> > Ok hope this is the last one. Please test.
> >
>
> Get same backtrace as in Comment #8
>

Just debug a bit, check out this series of calls in DRI2DestroyDrawable when X crashed:
in (*ds->DestroyBuffers)(pDraw, pPriv->buffers, pPriv->bufferCount);
  Xfree: free(0x9eef330)
  Xfree: free(0x9eeef20)
  Xfree: free(0x9efdde0)
  Xfree: free(0x9efce08)
  Xfree: free(0x9eee8b0)
  Xrealloc: ptr = 0x9efaf20
  Xrealloc: amount = 384
  Xfree: free(0x9efcd18)
  Xfree: free(0x9ef8468)
  Xrealloc: ptr = 0x9efa278
  Xrealloc: amount = 384
  Xfree: free(0x9efcd18)
  Xfree: free(0x9ef9808)
  Xfree: free(0x9eeef38)
  Xfree: free(0x9efa648)
  Xfree: free(0x9efd788)
in dixSetPrivate(&pPixmap->devPrivates, dri2PixmapPrivateKey, NULL);
  Xrealloc: ptr = 0x9efce08
  Xrealloc: amount = 512

So dixSetPrivate is trying to realloc memory at 0x9efce08, which is alreay freed in DetroyBuffers. So maybe we should also do this:
diff --git a/hw/xfree86/dri2/dri2.c b/hw/xfree86/dri2/dri2.c
index 0f2e24b..dddcfdc 100644
--- a/hw/xfree86/dri2/dri2.c
+++ b/hw/xfree86/dri2/dri2.c
@@ -204,9 +204,6 @@ DRI2DestroyDrawable(DrawablePtr pDraw)
     if (pPriv->refCount > 0)
        return;

- (*ds->DestroyBuffers)(pDraw, pPriv->buffers, pPriv->bufferCount);
- xfree(pPriv);
-
     if (pDraw->type == DRAWABLE_WINDOW)
     {
        pWin = (WindowPtr) pDraw;
@@ -217,6 +214,9 @@ DRI2DestroyDrawable(DrawablePtr pDraw)
        pPixmap = (PixmapPtr) pDraw;
        dixSetPrivate(&pPixmap->devPrivates, dri2PixmapPrivateKey, NULL);
     }
+
+ (*ds->DestroyBuffers)(pDraw, pPriv->buffers, pPriv->bufferCount);
+ xfree(pPriv);
 }

 Bool

[portis (portis24)]

I applied the patches by Jesse Barnes, and X crashed after some time.
Then I tried the patch by Shuang He, it didnot crash, but VT-swith no longer works. (I'm not sure whether it is caused by the patch)

The number of "drm mm object" still increases all the time.

And after 6h30m, sudo lsof | grep "drm mm object" | wc -l shows 14994.
And I got my /proc/dri/0/gem_objects:

18534 objects
1451909120 object bytes
4 pinned
12681216 pin bytes
247177216 gtt bytes
260313088 gtt total

Intel GM965
xf86-video-intel: 2.6.99
libdrm: 2.4.5
kernel: 2.6.29 with KMS enabled
mesa: 7.4rc1

[Shuang-he (shuang-he)]

(In reply to comment #14)
> I applied the patches by Jesse Barnes, and X crashed after some time.
> Then I tried the patch by Shuang He, it didnot crash, but VT-swith no longer
> works. (I'm not sure whether it is caused by the patch)
>
> The number of "drm mm object" still increases all the time.
>
> And after 6h30m, sudo lsof | grep "drm mm object" | wc -l shows 14994.
> And I got my /proc/dri/0/gem_objects:
>
> 18534 objects
> 1451909120 object bytes
> 4 pinned
> 12681216 pin bytes
> 247177216 gtt bytes
> 260313088 gtt total
>
>
> Intel GM965
> xf86-video-intel: 2.6.99
> libdrm: 2.4.5
> kernel: 2.6.29 with KMS enabled
> mesa: 7.4rc1
>

Jesse's patch in Comment #10 and mine in Comment #13 should be applied at the same time.

[Jesse Barnes (jbarnes-virtuousgeek)]

This is an X server bug.

[portis (portis24)]

(In reply to comment #15)
> (In reply to comment #14)
> > I applied the patches by Jesse Barnes, and X crashed after some time.
> > Then I tried the patch by Shuang He, it didnot crash, but VT-swith no longer
> > works. (I'm not sure whether it is caused by the patch)
> >
> > The number of "drm mm object" still increases all the time.
> >
> > And after 6h30m, sudo lsof | grep "drm mm object" | wc -l shows 14994.
> > And I got my /proc/dri/0/gem_objects:
> >
> > 18534 objects
> > 1451909120 object bytes
> > 4 pinned
> > 12681216 pin bytes
> > 247177216 gtt bytes
> > 260313088 gtt total
> >
> >
> > Intel GM965
> > xf86-video-intel: 2.6.99
> > libdrm: 2.4.5
> > kernel: 2.6.29 with KMS enabled
> > mesa: 7.4rc1
> >
>
> Jesse's patch in Comment #10 and mine in Comment #13 should be applied at the
> same time.
>

ok, I applied both patches. Now after 2h50m, I got:

sudo lsof | grep "drm mm object" | wc -l
5248

and /proc/dri/0/gem_objects:
13116 objects
1109676032 object bytes
4 pinned
12681216 pin bytes
186478592 gtt bytes
260313088 gtt total

[Frank Groeneveld (frankgroeneveld)]

I have the same problem on Jaunty with UXA enabled.

[drseergio (drseergio)]

(In reply to comment #17)
> (In reply to comment #15)
> > (In reply to comment #14)
> > > I applied the patches by Jesse Barnes, and X crashed after some time.
> > > Then I tried the patch by Shuang He, it didnot crash, but VT-swith no longer
> > > works. (I'm not sure whether it is caused by the patch)
> > >
> > > The number of "drm mm object" still increases all the time.
> > >
> > > And after 6h30m, sudo lsof | grep "drm mm object" | wc -l shows 14994.
> > > And I got my /proc/dri/0/gem_objects:
> > >
> > > 18534 objects
> > > 1451909120 object bytes
> > > 4 pinned
> > > 12681216 pin bytes
> > > 247177216 gtt bytes
> > > 260313088 gtt total
> > >
> > >
> > > Intel GM965
> > > xf86-video-intel: 2.6.99
> > > libdrm: 2.4.5
> > > kernel: 2.6.29 with KMS enabled
> > > mesa: 7.4rc1
> > >
> >
> > Jesse's patch in Comment #10 and mine in Comment #13 should be applied at the
> > same time.
> >
>
> ok, I applied both patches. Now after 2h50m, I got:
>
> sudo lsof | grep "drm mm object" | wc -l
> 5248
>
> and /proc/dri/0/gem_objects:
> 13116 objects
> 1109676032 object bytes
> 4 pinned
> 12681216 pin bytes
> 186478592 gtt bytes
> 260313088 gtt total
>
With these patches it is better indeed but, as mentioned, the memory usage is still abnormally high for X.

[Jesse Barnes (jbarnes-virtuousgeek)]

FYI, latest fix is from Michel (see below), hopefully it will be pushed soon.

diff --git a/glx/glxext.c b/glx/glxext.c
index c882372..e74d00e 100644
--- a/glx/glxext.c
+++ b/glx/glxext.c
@@ -119,17 +119,25 @@ static int ContextGone(__GLXcontext* cx, XID id)
 static Bool DrawableGone(__GLXdrawable *glxPriv, XID xid)
 {
     ScreenPtr pScreen = glxPriv->pDraw->pScreen;
+ PixmapPtr pPixmap = NULL;
+ int refcount;

     switch (glxPriv->type) {
  case GLX_DRAWABLE_PIXMAP:
  case GLX_DRAWABLE_PBUFFER:
- (*pScreen->DestroyPixmap)((PixmapPtr) glxPriv->pDraw);
+ pPixmap = (PixmapPtr) glxPriv->pDraw;
      break;
     }

- glxPriv->pDraw = NULL;
- glxPriv->drawId = 0;
+ refcount = glxPriv->refCount;
     __glXUnrefDrawable(glxPriv);
+ if (refcount > 1) {
+ glxPriv->pDraw = NULL;
+ glxPriv->drawId = 0;
+ }
+
+ if (pPixmap)
+ (*pScreen->DestroyPixmap)(pPixmap);

     return True;
 }

[drseergio (drseergio)]

(In reply to comment #19)
> FYI, latest fix is from Michel (see below), hopefully it will be pushed soon.
>
>
> diff --git a/glx/glxext.c b/glx/glxext.c
> index c882372..e74d00e 100644
> --- a/glx/glxext.c
> +++ b/glx/glxext.c
> @@ -119,17 +119,25 @@ static int ContextGone(__GLXcontext* cx, XID id)
> static Bool DrawableGone(__GLXdrawable *glxPriv, XID xid)
> {
> ScreenPtr pScreen = glxPriv->pDraw->pScreen;
> + PixmapPtr pPixmap = NULL;
> + int refcount;
>
> switch (glxPriv->type) {
> case GLX_DRAWABLE_PIXMAP:
> case GLX_DRAWABLE_PBUFFER:
> - (*pScreen->DestroyPixmap)((PixmapPtr) glxPriv->pDraw);
> + pPixmap = (PixmapPtr) glxPriv->pDraw;
> break;
> }
>
> - glxPriv->pDraw = NULL;
> - glxPriv->drawId = 0;
> + refcount = glxPriv->refCount;
> __glXUnrefDrawable(glxPriv);
> + if (refcount > 1) {
> + glxPriv->pDraw = NULL;
> + glxPriv->drawId = 0;
> + }
> +
> + if (pPixmap)
> + (*pScreen->DestroyPixmap)(pPixmap);
>
> return True;
> }
>

Should this patch be applied together with other patches? Patching fails on Xorg 1.6.

[portis (portis24)]

(In reply to comment #19)
> FYI, latest fix is from Michel (see below), hopefully it will be pushed soon.
>
>
> diff --git a/glx/glxext.c b/glx/glxext.c
> index c882372..e74d00e 100644
> --- a/glx/glxext.c
> +++ b/glx/glxext.c
> @@ -119,17 +119,25 @@ static int ContextGone(__GLXcontext* cx, XID id)
> static Bool DrawableGone(__GLXdrawable *glxPriv, XID xid)
> {
> ScreenPtr pScreen = glxPriv->pDraw->pScreen;
> + PixmapPtr pPixmap = NULL;
> + int refcount;
>
> switch (glxPriv->type) {
> case GLX_DRAWABLE_PIXMAP:
> case GLX_DRAWABLE_PBUFFER:
> - (*pScreen->DestroyPixmap)((PixmapPtr) glxPriv->pDraw);
> + pPixmap = (PixmapPtr) glxPriv->pDraw;
> break;
> }
>
> - glxPriv->pDraw = NULL;
> - glxPriv->drawId = 0;
> + refcount = glxPriv->refCount;
> __glXUnrefDrawable(glxPriv);
> + if (refcount > 1) {
> + glxPriv->pDraw = NULL;
> + glxPriv->drawId = 0;
> + }
> +
> + if (pPixmap)
> + (*pScreen->DestroyPixmap)(pPixmap);
>
> return True;
> }
>

This is what I get with this patch. After running 2h55m:

sudo lsof | grep "drm mm object" | wc -l
3695

cat /proc/dri/0/gem_objects
13819 objects
1520975872 object bytes
4 pinned
13828096 pin bytes
244764672 gtt bytes
260313088 gtt total

[Kristian Hoegsberg (krh-bitplanet)]

Created an attachment (id=24684)
full fix

This patch should fix the leak in all the different drawable destroy combinations. I'll push it as soon as I get a bit of positive feedback.

[Fdo (fdo)]

Thanks Kristian!

I don't suppose you (or anyone else) has a version of this fix that would apply on the 1.6 branch?

[Shuang-he (shuang-he)]

(In reply to comment #22)
> Created an attachment (id=24684) [details]
> full fix
>
> This patch should fix the leak in all the different drawable destroy
> combinations. I'll push it as soon as I get a bit of positive feedback.
>

I just play with it for half an hour, it works well, and didn't see the memory leak.
Thanks, Kristian.

[Peng-li (peng-li)]

Kristian, Can you also push this fix to 1.6 branch ?

[portis (portis24)]

(In reply to comment #22)
> Created an attachment (id=24684) [details]
> full fix
>
> This patch should fix the leak in all the different drawable destroy
> combinations. I'll push it as soon as I get a bit of positive feedback.
>

No luck for me. Mem usage still continuously increases.
After 1h30

$ cat /proc/dri/0/gem_objects
11499 objects
627249152 object bytes
4 pinned
13828096 pin bytes
120881152 gtt bytes
260313088 gtt total

$ sudo lsof | grep "drm mm object" | wc -l
4057

Is that normal?

[yangzhe1990 (yangzhe1990)]

I applied the patch with the xorg 1.6.0 source (and did some manually modification to let the patch work) and rebuiled it. But I think that there is only some improvement. By keep maximize/restore a window, the memory usage are raising, and afterall the memory and swap are used up

[yangzhe1990 (yangzhe1990)]

Oh, I'm sorry, after some minutes, the memory usage come backs to normal...

Will this work exactly this?

[Shuang-he (shuang-he)]

(In reply to comment #28)
> Oh, I'm sorry, after some minutes, the memory usage come backs to normal...
>
> Will this work exactly this?
>

It shouldn't use up all system memory, if you're only keeping maximize/restore a window. Kristian's patch is against xserver master branch, could you give it a try?

[Jesse Barnes (jbarnes-virtuousgeek)]

Kristian pushed the fix.

commit 7b6400a1b8d2f228fcbedf17c30a7e3924e4dd2a
Author: Kristian Høgsberg <email address hidden>
Date: Thu Apr 9 13:16:37 2009 -0400

    glx: Fix drawable private leak on destroy

[Shuang-he (shuang-he)]

(In reply to comment #28)
> Oh, I'm sorry, after some minutes, the memory usage come backs to normal...
>
> Will this work exactly this?
>

I think I see exactly what you met now.
In all, it seems not free system memory at the right time. So if we keep resizing the window for a few minutes, it will use up all system memory, and finally GPU hang. So there might be some issue with BO cache policy

And here's what I saw:
with KMS/UXA/DRI2/compiz. a few resizing will make memory usage grow rapidly
it will reach to use 1092860k, cat /proc/dri/0/gem_objects
2732 objects
552259584 object bytes
4 pinned
16977920 pin bytes
189448192 gtt bytes
234885120 gtt total

then if I don't operate for a few seconds, it seems start to free some memories.
so it use 859872k system memory, cat /proc/dri/0/gem_objects
3011 objects
276971520 object bytes
4 pinned
16977920 pin bytes
181391360 gtt bytes
234885120 gtt total

and if I start resizing the window again, it will reach to use 1440524k system memory, and cat /proc/dri/0/gem_objects
3394 objects
832200704 object bytes
4 pinned
16977920 pin bytes
179752960 gtt bytes
234885120 gtt total

and then if I keep resizing the window for a few minutes, it will use all system memory, then GPU hangs.

[Shuang-he (shuang-he)]

Ok, I have caught following leak on aspire one with KMS/UXA/DRI2/compiz, it just means 326 bo are lost in composite extension (the '0 bytes' is some trick I used with valgrind to catch such memory leak):

==14839== 0 bytes in 326 blocks are definitely lost in loss record 1 of 124
==14839== at 0x55AA62F: drm_intel_gem_bo_alloc_internal (intel_bufmgr_gem.c:4 28)
==14839== by 0x55A61C3: drm_intel_bo_alloc_for_render (intel_bufmgr.c:58)
==14839== by 0x55608B6: i830_uxa_create_pixmap (i830_exa.c:976)
==14839== by 0x8138E3B: compNewPixmap (compalloc.c:478)
==14839== by 0x81392D4: compAllocPixmap (compalloc.c:556)
==14839== by 0x8138939: compCheckRedirect (compwindow.c:161)
==14839== by 0x8138A2F: compRealizeWindow (compwindow.c:242)
==14839== by 0x806F9EB: RealizeTree (window.c:2605)
==14839== by 0x807179A: MapWindow (window.c:2698)
==14839== by 0x8139A9D: compRedirectWindow (compalloc.c:179)
==14839== by 0x8139D6C: compRedirectSubwindows (compalloc.c:320)
==14839== by 0x81368C1: ProcCompositeRedirectSubwindows (compext.c:172)

[Shuang-he (shuang-he)]

To summarize:
There seems two symptoms:
1. systems memories used by graphics driver will keep growing for a few times of resize operation, then drops dramatically, then grow again, and drops again ... If resize many times in very short time, it will consume all system memory and get X not resposible.
2. serious memory leak with composite, which will make graphics driver comsuming all system memory.
on my Q35, I see neither of them
on G45 and GM45, I see <1>, disable buffer reuse doesn't help here. it's desribed in comment #31
on aspire one, I see <2>, disable buffer reuse doesn't help here. it's desribed in comment #32

[Shuang-he (shuang-he)]

Seems pixmaps get refcnt incremented during I830DRI2CreateBuffers, but not dereferencing it corespondingly. Haven't tried this out, hope it would help:

diff --git a/src/i830_dri.c b/src/i830_dri.c
index 6a32492..633895b 100644
--- a/src/i830_dri.c
+++ b/src/i830_dri.c
@@ -1618,11 +1618,20 @@ I830DRI2DestroyBuffers(DrawablePtr pDraw, DRI2BufferPtr buffers, int count)
 {
     ScreenPtr pScreen = pDraw->pScreen;
     I830DRI2BufferPrivatePtr private;
+ PixmapPtr pDepthPixmap = NULL;
     int i;

     for (i = 0; i < count; i++)
     {
        private = buffers[i].driverPrivate;
+ if (buffers[i].attachment == DRI2BufferFrontLeft ||
+ buffers[i].attachment == DRI2BufferStencil && pDepthPixmap) {
+ private->pPixmap->refcnt--;
+ }
+
+ if (buffers[i].attachment == DRI2BufferDepth)
+ pDepthPixmap = private->pPixmap;
+
        (*pScreen->DestroyPixmap)(private->pPixmap);
     }

[portis (portis24)]

This patch does not work for me. Memory usage still increases.
And compiz leads to an X crash.

On Thu, Apr 23, 2009 at 4:45 PM, <email address hidden> wrote:

> http://bugs.freedesktop.org/show_bug.cgi?id=20704
>
>
>
>
>
> --- Comment #34 from Shuang He <email address hidden> 2009-04-23 07:45:55
> PST ---
> Seems pixmaps get refcnt incremented during I830DRI2CreateBuffers, but not
> dereferencing it corespondingly. Haven't tried this out, hope it would
> help:
>
> diff --git a/src/i830_dri.c b/src/i830_dri.c
> index 6a32492..633895b 100644
> --- a/src/i830_dri.c
> +++ b/src/i830_dri.c
> @@ -1618,11 +1618,20 @@ I830DRI2DestroyBuffers(DrawablePtr pDraw,
> DRI2BufferPtr
> buffers, int count)
> {
> ScreenPtr pScreen = pDraw->pScreen;
> I830DRI2BufferPrivatePtr private;
> + PixmapPtr pDepthPixmap = NULL;
> int i;
>
> for (i = 0; i < count; i++)
> {
> private = buffers[i].driverPrivate;
> + if (buffers[i].attachment == DRI2BufferFrontLeft ||
> + buffers[i].attachment == DRI2BufferStencil && pDepthPixmap) {
> + private->pPixmap->refcnt--;
> + }
> +
> + if (buffers[i].attachment == DRI2BufferDepth)
> + pDepthPixmap = private->pPixmap;
> +
> (*pScreen->DestroyPixmap)(private->pPixmap);
> }
>
>
> --
> Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug.
>

[Shuang-he (shuang-he)]

I've tried following configuration of codes:
Kernel_version: 2.6.29.1
Libdrm: (master)412d370b9ae4b2882691863a1c5e13a507574e92
Mesa: (mesa_7_4_branch)e8807a14a61a0b9389aa2f2a113da24ab22a364d
Xserver: (server-1.6-branch)11db545a86c8933c638a0bc1fcd4f2c65279f617
Xf86_video_intel: (2.7)296a986e5258e2fd13ec494071b7063bd639cd68
Kernel: (qa-branch)ba1d2a9be507cda299c15740ff7e2bb3705a4792

On aspire one, before start X, 110+MB memory is used, after start desktop with compiz, 380+MB memory is used, and after resizing windows for 10 minutes, 390+MB memory is used. And then if X is kill with SIGTERM, 210+MB is used.

On GM45, with same codes, still see issue 1 in comment #33

[portis (portis24)]

Shuang He,

With your patch, when I start compiz, X crashes:

Backtrace:
0: /usr/X11R6/bin/X(xorg_backtrace+0x28) [0x4a3a48]
1: /usr/X11R6/bin/X [0x431e3d]
2: /lib/libpthread.so.0 [0x7f6aa986e080]
3: /usr/lib/libdrm_intel.so.1(drm_intel_bo_flink+0) [0x7f6aa5be7840]
4: /usr/lib/xorg/modules/drivers/intel_drv.so [0x7f6aa5e4cd48]
5: /usr/lib/xorg/modules/extensions/libdri2.so(DRI2GetBuffers+0x10e)
[0x7f6aa609827e]
6: /usr/lib/xorg/modules/extensions/libdri2.so [0x7f6aa60987bd]
7: /usr/X11R6/bin/X [0x48e8e4]
8: /usr/X11R6/bin/X [0x42951d]
9: /lib/libc.so.6(__libc_start_main+0xe6) [0x7f6aa7bc05a6]
10: /usr/X11R6/bin/X [0x428969]
Segmentation fault at address 0x20

Fatal server error:
Caught signal 11 (Segmentation fault). Server aborting

My configuration:
kernel: 2.6.30-rc3
drm: (master)412d370b9ae4b2882691863a1c5e13a507574e92
mesa: (master)ff71587b27beaf288d535e14c75e58425d7efc7a
xserver: (master)0dfb97f15f591f85e079f5829c77d0c328d00464
xf86-video-intel: (master)106e4b44c5af6552cbd079c4ec34def9dcfb168a

On Fri, Apr 24, 2009 at 5:56 AM, <email address hidden> wrote:

> http://bugs.freedesktop.org/show_bug.cgi?id=20704
>
>
>
>
>
> --- Comment #36 from Shuang He <email address hidden> 2009-04-23 20:56:40
> PST ---
> I've tried following configuration of codes:
> Kernel_version: 2.6.29.1
> Libdrm: (master)412d370b9ae4b2882691863a1c5e13a507574e92
> Mesa: (mesa_7_4_branch)e8807a14a61a0b9389aa2f2a113da24ab22a364d
> Xserver: (server-1.6-branch)11db545a86c8933c638a0bc1fcd4f2c65279f617
> Xf86_video_intel:
> (2.7)296a986e5258e2fd13ec494071b7063bd639cd68
> Kernel: (qa-branch)ba1d2a9be507cda299c15740ff7e2bb3705a4792
>
> On aspire one, before start X, 110+MB memory is used, after start desktop
> with
> compiz, 380+MB memory is used, and after resizing windows for 10 minutes,
> 390+MB memory is used. And then if X is kill with SIGTERM, 210+MB is used.
>
> On GM45, with same codes, still see issue 1 in comment #33
>
>
> --
> Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug.
>

[Shuang-he (shuang-he)]

Oh, sorry for not making this clear.
What I mean is, with that configurations I list, without any other patch, I don't see serious leak on aspire one now. Could you help try that?

(In reply to comment #37)
> Shuang He,
>
> With your patch, when I start compiz, X crashes:
>
> Backtrace:
> 0: /usr/X11R6/bin/X(xorg_backtrace+0x28) [0x4a3a48]
> 1: /usr/X11R6/bin/X [0x431e3d]
> 2: /lib/libpthread.so.0 [0x7f6aa986e080]
> 3: /usr/lib/libdrm_intel.so.1(drm_intel_bo_flink+0) [0x7f6aa5be7840]
> 4: /usr/lib/xorg/modules/drivers/intel_drv.so [0x7f6aa5e4cd48]
> 5: /usr/lib/xorg/modules/extensions/libdri2.so(DRI2GetBuffers+0x10e)
> [0x7f6aa609827e]
> 6: /usr/lib/xorg/modules/extensions/libdri2.so [0x7f6aa60987bd]
> 7: /usr/X11R6/bin/X [0x48e8e4]
> 8: /usr/X11R6/bin/X [0x42951d]
> 9: /lib/libc.so.6(__libc_start_main+0xe6) [0x7f6aa7bc05a6]
> 10: /usr/X11R6/bin/X [0x428969]
> Segmentation fault at address 0x20
>
> Fatal server error:
> Caught signal 11 (Segmentation fault). Server aborting
>
> My configuration:
> kernel: 2.6.30-rc3
> drm: (master)412d370b9ae4b2882691863a1c5e13a507574e92
> mesa: (master)ff71587b27beaf288d535e14c75e58425d7efc7a
> xserver: (master)0dfb97f15f591f85e079f5829c77d0c328d00464
> xf86-video-intel: (master)106e4b44c5af6552cbd079c4ec34def9dcfb168a
>
>
> On Fri, Apr 24, 2009 at 5:56 AM, <email address hidden> wrote:
>
> > http://bugs.freedesktop.org/show_bug.cgi?id=20704
> >
> >
> >
> >
> >
> > --- Comment #36 from Shuang He <email address hidden> 2009-04-23 20:56:40
> > PST ---
> > I've tried following configuration of codes:
> > Kernel_version: 2.6.29.1
> > Libdrm: (master)412d370b9ae4b2882691863a1c5e13a507574e92
> > Mesa: (mesa_7_4_branch)e8807a14a61a0b9389aa2f2a113da24ab22a364d
> > Xserver: (server-1.6-branch)11db545a86c8933c638a0bc1fcd4f2c65279f617
> > Xf86_video_intel:
> > (2.7)296a986e5258e2fd13ec494071b7063bd639cd68
> > Kernel: (qa-branch)ba1d2a9be507cda299c15740ff7e2bb3705a4792
> >
> > On aspire one, before start X, 110+MB memory is used, after start desktop
> > with
> > compiz, 380+MB memory is used, and after resizing windows for 10 minutes,
> > 390+MB memory is used. And then if X is kill with SIGTERM, 210+MB is used.
> >
> > On GM45, with same codes, still see issue 1 in comment #33
> >
> >
> > --
> > Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
> > ------- You are receiving this mail because: -------
> > You are on the CC list for the bug.
> >
>

[portis (portis24)]

Sorry. I'll try to make my point clear. :)

With your patch, I cannot start compiz. And without compiz, I can hardly
tell if this patch fixes the leakage, because the leakage is noticeable only
when compiz is enabled. Maybe I'm in another situation.

BTW, I notice that in the file /proc/dri/0/gem_objects, the number of
objects always increases, even if I close all the windows. Unless I restart
X, this number never decreases. Is that normal? Is it related to the bug
discussed here?
Thanks for your help.

On Fri, Apr 24, 2009 at 5:33 PM, <email address hidden> wrote:

> http://bugs.freedesktop.org/show_bug.cgi?id=20704
>
>
>
>
>
> --- Comment #38 from Shuang He <email address hidden> 2009-04-24 08:33:14
> PST ---
> Oh, sorry for not making this clear.
> What I mean is, with that configurations I list, without any other patch, I
> don't see serious leak on aspire one now. Could you help try that?
>
>
> (In reply to comment #37)
> > Shuang He,
> >
> > With your patch, when I start compiz, X crashes:
> >
> > Backtrace:
> > 0: /usr/X11R6/bin/X(xorg_backtrace+0x28) [0x4a3a48]
> > 1: /usr/X11R6/bin/X [0x431e3d]
> > 2: /lib/libpthread.so.0 [0x7f6aa986e080]
> > 3: /usr/lib/libdrm_intel.so.1(drm_intel_bo_flink+0) [0x7f6aa5be7840]
> > 4: /usr/lib/xorg/modules/drivers/intel_drv.so [0x7f6aa5e4cd48]
> > 5: /usr/lib/xorg/modules/extensions/libdri2.so(DRI2GetBuffers+0x10e)
> > [0x7f6aa609827e]
> > 6: /usr/lib/xorg/modules/extensions/libdri2.so [0x7f6aa60987bd]
> > 7: /usr/X11R6/bin/X [0x48e8e4]
> > 8: /usr/X11R6/bin/X [0x42951d]
> > 9: /lib/libc.so.6(__libc_start_main+0xe6) [0x7f6aa7bc05a6]
> > 10: /usr/X11R6/bin/X [0x428969]
> > Segmentation fault at address 0x20
> >
> > Fatal server error:
> > Caught signal 11 (Segmentation fault). Server aborting
> >
> > My configuration:
> > kernel: 2.6.30-rc3
> > drm: (master)412d370b9ae4b2882691863a1c5e13a507574e92
> > mesa: (master)ff71587b27beaf288d535e14c75e58425d7efc7a
> > xserver: (master)0dfb97f15f591f85e079f5829c77d0c328d00464
> > xf86-video-intel: (master)106e4b44c5af6552cbd079c4ec34def9dcfb168a
> >
> >
> > On Fri, Apr 24, 2009 at 5:56 AM, <email address hidden>
> wrote:
> >
> > > http://bugs.freedesktop.org/show_bug.cgi?id=20704
> > >
> > >
> > >
> > >
> > >
> > > --- Comment #36 from Shuang He <email address hidden> 2009-04-23
> 20:56:40
> > > PST ---
> > > I've tried following configuration of codes:
> > > Kernel_version: 2.6.29.1
> > > Libdrm: (master)412d370b9ae4b2882691863a1c5e13a507574e92
> > > Mesa:
> (mesa_7_4_branch)e8807a14a61a0b9389aa2f2a113da24ab22a364d
> > > Xserver:
> (server-1.6-branch)11db545a86c8933c638a0bc1fcd4f2c65279f617
> > > Xf86_video_intel:
> > > (2.7)296a986e5258e2fd13ec494071b7063bd639cd68
> > > Kernel: (qa-branch)ba1d2a9be507cda299c15740ff7e2bb3705a4792
> > >
> > > On aspire one, before start X, 110+MB memory is used, after start
> desktop
> > > with
> > > compiz, 380+MB memory is used, and after resizing windows for 10
> minutes,
> > > 390+MB memory is used. And then if X is kill with SIGTERM, 210+MB is
> used.
> > >
> > > On GM45, with same codes, still see issue 1 in comment #33
> > >
> > >
> > > --
> > > Configure bugmail: http://...

[Shuang-he (shuang-he)]

I already knew that my patch is not working.
With that configurations I mentioned in comment #36, __without_any_patch__, (don't apply my patch, it's not fixing the problem), I don't see the leak any more.
And yes, it is the bug discussed here.

Thanks
  --Shuang
(In reply to comment #39)
> Sorry. I'll try to make my point clear. :)
> With your patch, I cannot start compiz. And without compiz, I can hardly
> tell if this patch fixes the leakage, because the leakage is noticeable only
> when compiz is enabled. Maybe I'm in another situation.
> BTW, I notice that in the file /proc/dri/0/gem_objects, the number of
> objects always increases, even if I close all the windows. Unless I restart
> X, this number never decreases. Is that normal? Is it related to the bug
> discussed here?
> Thanks for your help.

[Marius Gedminas (mgedmin)]

I'm a bit unclear: does the memory leak described in that freedesktop.org bug show up in top as memory used by the compiz process, or as used kernel memory, or both?

[Vitali Kulikou (sabotatore)]

Start compiz with "compiz.real --replace --sm-disable --ignore-desktop-hints ccp --indirect-rendering"! No memory leak!

[Kui-zheng (kui-zheng)]

in moblin latest image 2009-04-30 integrated xserver-1.6.1 with Kristian Høgsberg's patch the issue could be reproduced
then I try the following upstream components, it seems system mem would be consumed up for a while when keeping resize gears window

Platform -- Netbook (eepc, 945GME)
OSD -- moblin-netbook-20090428 image
Kernel -- (qa-branch)ba1d2a9be507cda299c15740ff7e2bb3705a4792
Libdrm -- (master)11b60973bca1bc9bbda44be4c695e22d28d8ca4a
Mesa -- (mesa_7_4_branch)e8807a14a61a0b9389aa2f2a113da24ab22a364d
Xserver -- (server-1.6-branch)11db545a86c8933c638a0bc1fcd4f2c65279f617
Xf86_video_intel -- (2.7)296a986e5258e2fd13ec494071b7063bd639cd68

[Ongion (benpy2k)]

Vitali, that fix causes some problems with transparency. The fix for a certain UXA transparency bug was to turn off indirect-rendering.

[Ongion (benpy2k)]

On further thought, however, that bug was more likely a problem with indirect-rendering itself. I'll see if a bug report has been submitted to compiz about it.

[Fujiyama (medtorke)]

i have the same problem, but compiz.real dont use only too match memory but cpu too, up to 70 percent of cpu usage is reserved to it, i use a laptop and cpu usage is important and have a direct effects for battery life time.

[Fujiyama (medtorke)]

hi all, i think i found the solution, at least for me, with integrated graphics, simply we have to edit xorg.conf , this is what we have to inject
  Section "Device"
          Identifier "Configured Video Device"
          Driver "intel"
          Option "AccelMethod" "EXA"
          Option "MigrationHeuristic" "greedy"
  EndSection

just edit the device's section to adapt it to this one
now, cpu usage is max 35 percent, and even less .
be sure to keep a bachup of your original xorg.conf.

i use ubuntu 9.04 jaunty

[Fujiyama (medtorke)]

hi all, i think i found the solution, at least for me, becose compiz.real use no more cpu, with integrated graphics, simply we have to edit xorg.conf , this is what we have to inject
  Section "Device"
          Identifier "Configured Video Device"
          Driver "intel"
          Option "AccelMethod" "EXA"
          Option "MigrationHeuristic" "greedy"
  EndSection

just edit the device's section to adapt it to this one
now, cpu usage is max 35 percent, and even less .
be sure to keep a bachup of your original xorg.conf.

i use ubuntu 9.04 jaunty

[emms (emms007)]

Hi

@Fujiyama: Switching back to EXA is not really a solution.

I use the latest intel driver and xorg 7.4~5ubuntu18 from jaunty repo and regular Xorg.conf with UXA set. I do experience the same issue.
I am running KDE with Kwin native composite engine. Even with special effect the ram gets filled upand so does the swap.

I don't have a clue which process does the leak. Htop reports high memory use:
3303M as VIRT
261M as RES
105M as SHAR

My swap is full up to 918/956 mb eventough I have only 1024/3790 of Ram used.
I wonder how to debug further. I can't test to go back to EXA as latest Intel driver are now UXA only.

[Fujiyama (medtorke)]

@emms, yes it isn't a solution,it's a temporary solution, the bug is confirmed and no solutions until now, we can't work with a laptop that 1 process use 80 percent of it's cpu and as you mentioned for the memory, so at least, we have to act .

On the Ubuntu 9.04 release note, they mention that using UXA mode for Intel Video Driver will have a better performance. However, they also warn that UXA mode is experimental, so it could be very not stable.
to use the EXA mode you have first to downgrade your intel driver like i did
The way to rollback the original Ubuntu Intel video driver:
$ sudo apt-get install xserver-xorg-video-intel

[Guiodic (Guido Iodice) (guido-iodice)]

I can confirm the bug on my hard/soft configuration:

card: i915 gm
os: Ubuntu 9.04 *
kernel: linux 2.6.30 rc6 vanilla
xorg driver version: 2.7.1 stable
libdrm-intel: 2.4.9
mesa: 7.4.1

* I have installed on Ubuntu Jaunty packages from xorg-update PPA repos and mesa from karmic repos: this not solves the issue.

[Shuang-he (shuang-he)]

for symtom 1 desribed in commet #43(In reply to comment #33)
> To summarize:
> There seems two symptoms:
> 1. systems memories used by graphics driver will keep growing for a few times
> of resize operation, then drops dramatically, then grow again, and drops again
> ... If resize many times in very short time, it will consume all system memory
> and get X not resposible.
> 2. serious memory leak with composite, which will make graphics driver
> comsuming all system memory.
> on my Q35, I see neither of them
> on G45 and GM45, I see <1>, disable buffer reuse doesn't help here. it's
> desribed in comment #31
> on aspire one, I see <2>, disable buffer reuse doesn't help here. it's desribed
> in comment #32
>

For the symptom <1>, it seems it's the result of 965 state cache.
I have tracked it with valgrind (with VALGRIND_PRINTF_BACKTRACE), following is one of the buffer object I checked, you can see buffer object 474 is allocated when a window is created, and this buffer object is deleted much later in brw_clear_cache

**6022** shuang 443 alloc: handle=474, size=256 KB
==6022== at 0x5511171: VALGRIND_PRINTF_BACKTRACE (valgrind.h:3695)
==6022== by 0x5511CF8: drm_intel_gem_bo_alloc_internal (intel_bufmgr_gem.c:437)
==6022== by 0x550D473: drm_intel_bo_alloc_for_render (intel_bufmgr.c:58)
==6022== by 0x52978AE: intel_region_alloc (intel_regions.c:173)
==6022== by 0x52968A1: intel_miptree_create (intel_mipmap_tree.c:122)
==6022== by 0x52B761B: intelTexImage (intel_tex_image.c:132)
==6022== by 0x52B80CD: intelTexImage2D (intel_tex_image.c:587)
==6022== by 0x5370B19: _mesa_TexImage2D (teximage.c:2676)
==6022== by 0x45A021D: (within /usr/lib/tmp/libclutter-glx-0.9.so.0.903.0)
==6022== by 0x45A04E8: cogl_texture_new_from_data (in /usr/lib/tmp/libclutter-glx-0.9.so.0.903.0)
==6022== by 0x80A8F2F: (within /usr/bin/metacity)
==6022== by 0x80A9112: (within /usr/bin/metacity)

**6022** shuang 6130 delete: handle=474, size=256 KB
==6022== at 0x5511171: VALGRIND_PRINTF_BACKTRACE (valgrind.h:3695)
==6022== by 0x551131E: drm_intel_gem_bo_unreference_locked (intel_bufmgr_gem.c:573)
==6022== by 0x55112AD: drm_intel_gem_bo_unreference_locked (intel_bufmgr_gem.c:582)
==6022== by 0x55112AD: drm_intel_gem_bo_unreference_locked (intel_bufmgr_gem.c:582)
==6022== by 0x5511791: drm_intel_gem_bo_unreference (intel_bufmgr_gem.c:621)
==6022== by 0x550D4B5: drm_intel_bo_unreference (intel_bufmgr.c:73)
==6022== by 0x52D0B2A: brw_clear_cache (brw_state_cache.c:501)
==6022== by 0x52D8C8C: brw_note_unlock (brw_vtbl.c:184)
==6022== by 0x528C43B: UNLOCK_HARDWARE (intel_context.c:1078)
==6022== by 0x52C58EA: brw_draw_prims (brw_draw.c:417)
==6022== by 0x538E59B: vbo_exec_DrawRangeElements (vbo_exec_array.c:435)
==6022== by 0x5382EB9: neutral_DrawRangeElements (vtxfmt_tmp.h:343)

If I reduced the limit of cached items, this symptom will disappear:

diff --git a/src/mesa/drivers/dri/i965/brw_state_cache.c b/src/mesa/drivers/dri/i965/brw_state_cache.c
index e40d7a0..0afb7af 100644
--- a/src/mesa/drivers/dri/i965/brw_state_cache.c
+++ b/src/mesa/drivers/dri/i965/brw_state_cache.c
@@ -527,10 +527,10 @@ brw_state_ca...

[Shuang-he (shuang-he)]

Created an attachment (id=26326)
Buffers created for fb should be released when destroy drawable

[Shuang-he (shuang-he)]

Created an attachment (id=26327)
Buffers created for fb should be released when destroy drawable

[Shuang-he (shuang-he)]

(In reply to comment #45)
> Created an attachment (id=26327) [details]
> Buffers created for fb should be released when destroy drawable
>

copy-n－paste failure, should be:
glXReleaseTexImageEXT should release reference to storage for the pixmap

[Shuang-he (shuang-he)]

Created an attachment (id=26328)
glXReleaseTexImageEXT should release reference to storage for the pixmap

reupload

[Shuang-he (shuang-he)]

Patches in comment #44 and comment #47 need to be applied to mesa at the same time. And there's also an issue in compiz, that according to GLX 1.4 spec, "however, GLXPixmaps created by call other than glXCreateGLXPixmap should not be passed to glXDestroyGLXPixmap", so compiz should use glXDestroyPixmap instead of glXDestroyGLXPixmap, since their pixmaps are created by calling glXCreatePixmap.

[Sebastian Rühl (sebastian-ruehl)]

same problem here:
after 30 min idle:

             total used free shared buffers cached
Mem: 1945 1759 186 0 92 1063
-/+ buffers/cache: 603 1342
Swap: 3816 14 3802

after echo 3 | sudo tee /proc/sys/vm/drop_caches

             total used free shared buffers cached
Mem: 1945 954 991 0 0 420
-/+ buffers/cache: 534 1411
Swap: 3816 14 3802

anyway its a big waste of memory and makes the sys inresponsible
The use of 900mb could be a reason of using 64 bit...

[Petar Velkovski (pvelkovski)]

I'm having the same problem in Ubuntu 9.04 with intel GMA950 graphics. I use intel drivers from xorg-edgers PPA. i am still not sure if it is compiz bug or a intel driver bug or something else. All I know is that after a few hours or mostly a day of usage of my system, the swap drive is getting full (compiz.real uses 1.3GB od virtual memory) and I get noticeable slowdown of the system. Also because I keep firefox open all the time, there appears a problem with font rendering of the new pages I open. Some of the letters become weird, if I zoom in or out the text, some of the letters become readable again, while others become scrambled. Considering the fact that my system is anything but a standard 9.04 installation (because of the now famous Intel graphic driver fiasco) I am not really sure what part of the system to really blame. Is it the kernel (linux kernel 2.6.30rc8 from kernel PPA), is it the mesa drivers or intel driver or whatever that comes from xorg-edgers PPA, or maybe the problem appeared from the compiz upgrade from jaunty-proposed repository, or is it firefox 3.5b4 that I use. All I know is that after a few hours or mostly a day, I have to restart my computer. It's like Bil Gates took over the development of Ubuntu.

[Dark-shadow (dark-shadow)]

Applied patches 2 and 3, as 1 is already in git (correct me if I'm wrong).
Compiz is unstable and crashes when using the ring switcher plugin, and also when opening many many windows, so removed both patches again.

> so compiz should use glXDestroyPixmap instead of glXDestroyGLXPixmap,
> since their pixmaps are created by calling
> glXCreatePixmap.

Corrected occurences in textures.c, seems to work ok but can't tell about any differences yet.

cat /proc/dri/0/gem_objects
1294 objects
153399296 object bytes
4 pinned
13770752 pin bytes
125480960 gtt bytes
260308992 gtt total

Objects increase quite a lot, but memory is not consumed that fast. Should the objects decrease after closing a window?

Using kernel-2.6.30.

[Shuang-he (shuang-he)]

(In reply to comment #49)
> Applied patches 2 and 3, as 1 is already in git (correct me if I'm wrong).
> Compiz is unstable and crashes when using the ring switcher plugin, and also
> when opening many many windows, so removed both patches again.
>
> > so compiz should use glXDestroyPixmap instead of glXDestroyGLXPixmap,
> > since their pixmaps are created by calling
> > glXCreatePixmap.
>
> Corrected occurences in textures.c, seems to work ok but can't tell about any
> differences yet.
>
>
> cat /proc/dri/0/gem_objects
> 1294 objects
> 153399296 object bytes
> 4 pinned
> 13770752 pin bytes
> 125480960 gtt bytes
> 260308992 gtt total
>
> Objects increase quite a lot, but memory is not consumed that fast. Should the
> objects decrease after closing a window?
>
> Using kernel-2.6.30.
>
Thanks for your testing. Could you attach the backtrace of the crash.
With those two patches and corrected compiz, memory usage shall not increase much when you keep resizing one window on 945GM.

[Shuang-he (shuang-he)]

an update version of patch in comment #44 has been commited.
the patch in comment #47 has problem with some compiz plug-in, and it's not a must to fix this memory leak issue, but the compiz fix is needed which is described in comment #48.

I can't reproduce this issue any more on 945GM with fix in compiz, my configuration is:
Libdrm (master)2fa2db138ba989bfa1a8cd9ab66d83fb7369249e
Mesa (master)77506dac8e81e9548a7e9680ce367175fe5747af
Xserver (master)14581afb474552716c02ca15220ca7050123c375
Xf86_video_intel (master)b5cd2130f97591f4a387db1b98c940c30bc6404c
Kernel (for-linus)0e7ddf7eeeef5aea85412120539ab5369577faeb

[Dark-shadow (dark-shadow)]

I also updated to latest git recently (a week ago?) and do not experience the bug anymore, with the compiz fix described in comment #48 applied. I still have problems when memory usage is high, leading to pixmap corruption and finally freezing the system. I will open another bug report when I am able to reproduce this. So far, thanks for your help, everything works much better now.

[Dark-shadow (dark-shadow)]

Perhaps I should also mention that I pulled Eric Anholt's drm branch from git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel.git
which contains quite a few changes, and I am using latest git now.

[Fdo (fdo)]

(In reply to comment #51)
> an update version of patch in comment #44 has been commited.

For packagers wanting to cherry-pick, the commit is: d027e8feff7d38cccadc6aaccc0454b21ce4dca0

Thanks for your work Shuang

[Jason Smith (jassmith)]

A simple 2 line patch to compiz is required to make this work right. The upstream fix wont resolve the issue until compiz is patched

[Shuang-he (shuang-he)]

Verified

[Sebastian Rühl (sebastian-ruehl)]

is there a fixed package for compiz available?

[Petar Velkovski (pvelkovski)]

Using "indirect rendering" option for compiz solves this memory leak.

1. Press ALT+F2 and type:
gksudo gedit /usr/bin/compiz

or

open your console and type:
sudo gedit /usr/bin/compiz

2. At line 74 (or round 74) edit the line :

COMPIZ_OPTIONS="--ignore-desktop-hints --replace"
and changed it into:
COMPIZ_OPTIONS="--replace --sm-disable --ignore-desktop-hints ccp --indirect-rendering"

After this there was no compiz memory leak. The compiz bug report mentions that with "indirect rendering" enabled, there is another problem, like a bug in rendering transparent windows, but that bug does not appear at my system. All this is done in combination with
xf86-video-intel 2.7.99.1+git2009 from https://launchpad.net/~xorg-edgers/+archive/ppa and all the other updates from that repository (mesa, dri2 etc.) and also kernel 2.6.30.

[Sebastian Rühl (sebastian-ruehl)]

is use the 2:2.7.1-0ubuntu1~xup~1 and the 2.6.30-10 kernel.
I will give that option a try. But what exactly happens when I enable --indirect-redering. Wasn't able to find in the man file the meaning of that option.

[Sebastian Rühl (sebastian-ruehl)]

sorry. I have forgotten to mention that; I have kms enabled

[Petar Velkovski (pvelkovski)]

Sebastian i don't have a clue what that option means, but it obviously fixed the memory leak bug. By the way this options showed up while I was "working" with python.

When I typed help() in python and than used "modules" command, python started scanning the modules and somehow restarted compiz with this options (probably some kind of bug). All I know that memory got "cleaned" and there was no memory leak anymore.

I am mentioning this because I use Compiz Fusion Icon. It's an application that sits in the notification area and allows you easy access to compiz options etc. There is a checkbox in the popup meny you get when you click on this icon, that allows you to chose Indirect rendering as option for compiz. But it doesn't work. If you choose "Indirect rendering" in this menu, the memory leak was still present. Changing /usr/bin/compiz solved my problem.

[Petar Velkovski (pvelkovski)]

By the way can you tell us how you have kms enabled. I thought that it was on by default in 2.6.30. How can someone see if kms is enabled, or set it enabled or disabled? ( I know that this is not a forum to ask questions, but I suppose it helps us diagnose our systems and resolve bugs)

[Sebastian Rühl (sebastian-ruehl)]

I can't remember currently where I found this but you need to do following:

create a file /etc/modprobe.d/i915-kms.conf

and insert this content. :

options i915 modeset=1

this should be all...

[Alexandros (alexandros-t)]

I don't think it has to do with kms. I am using 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03) (according to lspci), with UXA enabled and after a few hours 50% (~500/1024MiB) of my system's RAM and 100% of my swapfile (256 MiB) is allocated.

[Sebastian Rühl (sebastian-ruehl)]

maybe these are related:

http://bugs.freedesktop.org/show_bug.cgi?id=20704

http://bugzilla.kernel.org/show_bug.cgi?id=13294

https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/360319

[Alexandros (alexandros-t)]

I got a memory leak, switched from Compiz to Metacity and there was a drop in memory usage (can't remember how much), but it was not significant. I think that we should add xserver-xorg-video-intel in "Affects", because this bug is definitely not Compiz-exclusive.

[mehturt (mehturt)]

Alexandros, if what you see is not a different bug, then I'm having this problem as well.. Tons of leaks in Xorg, using E17. My colleague has leaks as well on the same HW as me, he's using KDE.

[Alexandros (alexandros-t)]

I found a symptom of the memory leak:
Type on a terminal this command:

watch -n 1 cat /proc/dri/0/gem_objects

and continue working while looking at the output of the terminal. You will notice that the number of objects allocated never decreases.

[Alexandros (alexandros-t)]

I just logged myself out and re-logged in:
Before logging out:5300(about) objects allocated
While writing this:974 objects allocated (with only firefox and gnome-terminal open)
(excact output:)
974 objects
123801600 object bytes
2 pinned
8519680 pin bytes
110321664 gtt bytes
253972480 gtt total

[Sergiy Zuban (s-zuban)]

someone wrote that leak occurs only in non-KMS mode - it's not true.
I'm on 2.6.31-2 kernel from karmic with KMS enabled and still has memory leak.

[mehturt (mehturt)]

Ok, so it's not my leak. Last afternoon I had 1530 objects, this morning the number of objects is the same, but the Xorg memory grew to 1270m VIRT and 859m RES.

[Alexandros (alexandros-t)]

I've just tested with EXA:
alexandros@ubuntu:~$ cat /proc/dri/0/gem_objects
268 objects
91148288 object bytes
4 pinned
50462720 pin bytes
70754304 gtt bytes
222515200 gtt total

I also switched from Compiz to Metacity and the output was exactly the same.

I think there is a problem not only with Compiz, but also with X and the Intel driver. Should we add xserver-xorg and xserver-xorg-video-intel as being affected?

[Sebastian Rühl (sebastian-ruehl)]

this bug is a real pain...
Im running a 64bit Jaunty on a X61T with this driver 2:2.7.1-0ubuntu1~xup~1
I tried to install the 2.8 but after this the Xserver wasn't any more able to load the drivers... I posted in another bug report if someone can post a working configuration for 2.8 but still no response. Maybe somebody here has the 2.8 running.?

[Sergiy Zuban (s-zuban)]

i'm on 2.8.0+git20090724.9a45ace2-0ubuntu0sarvatt~jaunty (32bit) and still experience memory leaks (~50-100MB of swap used when I have more then 1.5GB of unused RAM).

[Travis Watkins (amaranth)]

That is not a memory leak, that is (somewhat) normal behavior. The memory leak described in this bug would be if you had few apps open but all of your RAM was used and the system was starting to use a lot of swap too.

[garijon (garijon)]

Same problem here, full memory, full swap, almost frozen machine.
I am running ubuntu jaunty with 2.6.30 kernel.

[Petar Velkovski (pvelkovski)]

garijon have you tried my suggestion at #17?

[Sebastian Rühl (sebastian-ruehl)]

@Petar
I tried it like you suggested but the leak still occurs...

[garijon (garijon)]

Petar,
  I tried your suggestion #17, and although my system now works better and
longer, I end up with all my memory and swap consumed and needing a reboot.

On Sat, Aug 1, 2009 at 3:50 PM, Petar Velkovski <email address hidden>wrote:

> garijon have you tried my suggestion at #17?
>
> --
> [Jaunty][UXA]compiz.real memory leak
> https://bugs.launchpad.net/bugs/328232
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[Petar Velkovski (pvelkovski)]

I doubt this will be fixed soon.

Just for a reference this is the package sources I use:

deb http://archive.ubuntu.com/ubuntu/ jaunty universe
deb-src http://archive.ubuntu.com/ubuntu/ jaunty universe
deb http://archive.ubuntu.com/ubuntu/ jaunty-updates universe
deb-src http://archive.ubuntu.com/ubuntu/ jaunty-updates universe
deb http://archive.ubuntu.com/ubuntu/ jaunty multiverse
deb-src http://archive.ubuntu.com/ubuntu/ jaunty multiverse
deb http://archive.ubuntu.com/ubuntu/ jaunty-updates multiverse
deb-src http://archive.ubuntu.com/ubuntu/ jaunty-updates multiverse
deb http://archive.ubuntu.com/ubuntu/ jaunty-backports main restricted universe multiverse
deb http://archive.ubuntu.com/ubuntu/ jaunty-security main restricted
deb-src http://archive.ubuntu.com/ubuntu/ jaunty-security main restricted
deb http://archive.ubuntu.com/ubuntu/ jaunty-security universe
deb-src http://archive.ubuntu.com/ubuntu/ jaunty-security universe
deb http://archive.ubuntu.com/ubuntu/ jaunty-security multiverse
deb-src http://archive.ubuntu.com/ubuntu/ jaunty-security multiverse
deb http://ppa.launchpad.net/xorg-edgers/ppa/ubuntu jaunty main *
deb http://archive.ubuntu.com/ubuntu/ jaunty-proposed restricted main multiverse universe
deb http://ppa.launchpad.net/rvm/smplayer/ubuntu jaunty main
deb http://ppa.launchpad.net/inkscape.testers/ppa/ubuntu jaunty main
deb http://download.virtualbox.org/virtualbox/debian jaunty non-free
deb http://ppa.launchpad.net/anyremote/ppa/ubuntu jaunty main
deb http://ppa.launchpad.net/compiz/ppa/ubuntu jaunty main #compiz-fusion *
deb http://ppa.launchpad.net/lidaobing/ppa/ubuntu jaunty main #chmsee
deb http://ppa.launchpad.net/ubuntu-x-swat/x-updates/ubuntu jaunty main #ubuntu-x *
deb http://ppa.launchpad.net/c-korn/vlc/ubuntu jaunty main
deb http://www.ubuntutrucchi.it/repository ubuntu main non-free
deb http://ftp.osuosl.org/pub/pculture.org/miro/linux/repositories/ubuntu jaunty/

(those marked with * are probably most relevant)

uname -a
Linux aurora 2.6.30-10-generic #12-Ubuntu SMP Wed Jun 24 17:15:00 UTC 2009 i686 GNU/Linux

lspci
...
00:02.0 VGA compatible controller: Intel Corporation 82945G/GZ Integrated Graphics Controller (rev 02)
...

I don't experience any memory leaks after making the changes in #17.

petar@aurora:~$ cat /proc/dri/0/gem_objects
679 objects
183341056 object bytes
3 pinned
23965696 pin bytes
126930944 gtt bytes
260308992 gtt total

I have no understanding of the meaning of the numbers above.

petar@aurora:~$ uptime
 16:31:20 up 14:29, 1 user, load average: 0.10, 0.25, 0.52

petar@aurora:~$ cat /proc/meminfo
MemTotal: 2052400 kB
MemFree: 706544 kB
Buffers: 46464 kB
Cached: 792488 kB
SwapCached: 7252 kB
Active: 489480 kB
Inactive: 803820 kB
Active(anon): 303960 kB
Inactive(anon): 303240 kB
Active(file): 185520 kB
Inactive(file): 500580 kB
Unevictable: 8 kB
Mlocked: 8 kB
HighTotal: 1178184 kB
HighFree: 305536 kB
LowTotal: 874216 kB
LowFree: 401008 kB
SwapTotal: 2465936 kB
SwapFree: 2441008 kB
Dirty: 100 kB
Writeback: 0 kB
AnonPages: ...

[STaRMaN (jarizaro)]

To Sergiy Zuban #29
"I'm on 2.6.31-2 kernel from karmic with KMS enabled and still has memory leak."

In next bug (duplicated i think), a guy says the problem is solved in Karmic
http://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/410248
comment #5

I'm having this bug in jaunty with kde 4.3
Intel GMA x3100. (GM965)

[Travis Watkins (amaranth)]

This is fixed in the compiz packages in karmic.

[STaRMaN (jarizaro)]

Could someone build/say the fix for Jaunty?
Thanks