[Jaunty][UXA]compiz.real memory leak
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Compiz |
Fix Released
|
High
|
|||
compiz (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Bug Description
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+
ii xserver-
ii xserver-xorg-core 2:1.5.99.

Bart Kroon (tarmack) wrote : | #1 |
Changed in compiz: | |
status: | New → Confirmed |

|
#2 |
System Environment:
-------
Libdrm: (master)
Mesa: (mesa_7_
Xserver: (server-
Xf86_video_
Kernel: (for-airlied)
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

|
#3 |
Created an attachment (id=23950)
xorg log

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

|
#5 |
This is for moblin bug 1218.

|
#6 |
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.

|
#7 |
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 __glXDRIdrawabl

|
#8 |
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. :)

|
#9 |
(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

|
#10 |
(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=
at privates.c:129
#9 0x0806d1cc in dixSetPrivate (privates=
at privates.c:193
#10 0xb7e8eca1 in DRI2DestroyDrawable (pDraw=0x91487b0) at dri2.c:218
#11 0xb7eee668 in __glXDRIdrawabl
#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, skipDeleteFuncT
at resource.c:561
#15 0xb7edffa6 in DoDestroyDrawable (cl=<value optimized out>,
glxdrawable
#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

|
#11 |
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) wrote : | #12 |
You can try this patch for xserver,
http://
which is mentioned in the following bug report:
http://
It works for me, although it seems still have file descriptor leakage.

|
#13 |
Created an attachment (id=24328)
leak fix
Ok hope this is the last one. Please test.

|
#14 |
The last leak fix does not work for me...
Backtrace:
0: /usr/bin/
1: /usr/bin/
2: [0xb8071400]
3: /usr/bin/
4: /usr/lib/
5: /usr/lib/
6: /usr/lib/
7: /usr/lib/
8: /usr/bin/
9: /usr/lib/
10: /usr/lib/
11: /usr/bin/
12: /usr/bin/
13: /lib/libc.
14: /usr/bin/X [0x806f411]
Fatal server error:
Caught signal 11. Server aborting

|
#15 |
(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

|
#16 |
(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->DestroyBu
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(
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/
index 0f2e24b..dddcfdc 100644
--- a/hw/xfree86/
+++ b/hw/xfree86/
@@ -204,9 +204,6 @@ DRI2DestroyDraw
if (pPriv->refCount > 0)
return;
- (*ds->DestroyBu
- xfree(pPriv);
-
if (pDraw->type == DRAWABLE_WINDOW)
{
pWin = (WindowPtr) pDraw;
@@ -217,6 +214,9 @@ DRI2DestroyDraw
pPixmap = (PixmapPtr) pDraw;
}
+
+ (*ds->DestroyBu
+ xfree(pPriv);
}
Bool

|
#17 |
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/
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

|
#18 |
(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/
>
> 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.

|
#19 |
This is an X server bug.

|
#20 |
(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/
> >
> > 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/
13116 objects
1109676032 object bytes
4 pinned
12681216 pin bytes
186478592 gtt bytes
260313088 gtt total

Frank Groeneveld (frankgroeneveld) wrote : | #21 |
I have the same problem on Jaunty with UXA enabled.

|
#22 |
(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/
> > >
> > > 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/
> 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.

|
#23 |
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(
static Bool DrawableGone(
{
ScreenPtr pScreen = glxPriv-
+ PixmapPtr pPixmap = NULL;
+ int refcount;
switch (glxPriv->type) {
case GLX_DRAWABLE_
case GLX_DRAWABLE_
- (*pScreen-
+ pPixmap = (PixmapPtr) glxPriv->pDraw;
break;
}
- glxPriv->pDraw = NULL;
- glxPriv->drawId = 0;
+ refcount = glxPriv->refCount;
__
+ if (refcount > 1) {
+ glxPriv->pDraw = NULL;
+ glxPriv->drawId = 0;
+ }
+
+ if (pPixmap)
+ (*pScreen-
return True;
}

|
#24 |
(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(
> static Bool DrawableGone(
> {
> ScreenPtr pScreen = glxPriv-
> + PixmapPtr pPixmap = NULL;
> + int refcount;
>
> switch (glxPriv->type) {
> case GLX_DRAWABLE_
> case GLX_DRAWABLE_
> - (*pScreen-
> + pPixmap = (PixmapPtr) glxPriv->pDraw;
> break;
> }
>
> - glxPriv->pDraw = NULL;
> - glxPriv->drawId = 0;
> + refcount = glxPriv->refCount;
> __glXUnrefDrawa
> + if (refcount > 1) {
> + glxPriv->pDraw = NULL;
> + glxPriv->drawId = 0;
> + }
> +
> + if (pPixmap)
> + (*pScreen-
>
> return True;
> }
>
Should this patch be applied together with other patches? Patching fails on Xorg 1.6.

|
#25 |
(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(
> static Bool DrawableGone(
> {
> ScreenPtr pScreen = glxPriv-
> + PixmapPtr pPixmap = NULL;
> + int refcount;
>
> switch (glxPriv->type) {
> case GLX_DRAWABLE_
> case GLX_DRAWABLE_
> - (*pScreen-
> + pPixmap = (PixmapPtr) glxPriv->pDraw;
> break;
> }
>
> - glxPriv->pDraw = NULL;
> - glxPriv->drawId = 0;
> + refcount = glxPriv->refCount;
> __glXUnrefDrawa
> + if (refcount > 1) {
> + glxPriv->pDraw = NULL;
> + glxPriv->drawId = 0;
> + }
> +
> + if (pPixmap)
> + (*pScreen-
>
> 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/
13819 objects
1520975872 object bytes
4 pinned
13828096 pin bytes
244764672 gtt bytes
260313088 gtt total

|
#26 |
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.

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

|
#28 |
(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.

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

|
#30 |
(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/
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?

|
#31 |
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

|
#32 |
Oh, I'm sorry, after some minutes, the memory usage come backs to normal...
Will this work exactly this?

|
#33 |
(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?
Changed in compiz: | |
status: | Unknown → Confirmed |

|
#34 |
Kristian pushed the fix.
commit 7b6400a1b8d2f22
Author: Kristian Høgsberg <email address hidden>
Date: Thu Apr 9 13:16:37 2009 -0400
glx: Fix drawable private leak on destroy
Changed in compiz: | |
status: | Confirmed → Fix Released |

|
#35 |
(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/
it will reach to use 1092860k, cat /proc/dri/
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/
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/
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.

|
#36 |
Ok, I have caught following leak on aspire one with KMS/UXA/
==14839== 0 bytes in 326 blocks are definitely lost in loss record 1 of 124
==14839== at 0x55AA62F: drm_intel_
==14839== by 0x55A61C3: drm_intel_
==14839== by 0x55608B6: i830_uxa_
==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: compRedirectSub
==14839== by 0x81368C1: ProcCompositeRe

|
#37 |
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
Changed in compiz: | |
status: | Fix Released → Confirmed |

|
#38 |
Seems pixmaps get refcnt incremented during I830DRI2CreateB
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 @@ I830DRI2Destroy
{
ScreenPtr pScreen = pDraw->pScreen;
I830DRI2Bu
+ PixmapPtr pDepthPixmap = NULL;
int i;
for (i = 0; i < count; i++)
{
private = buffers[
+ if (buffers[
+ buffers[
+ private-
+ }
+
+ if (buffers[
+ pDepthPixmap = private->pPixmap;
+
}

|
#39 |
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://
>
>
>
>
>
> --- Comment #34 from Shuang He <email address hidden> 2009-04-23 07:45:55
> PST ---
> Seems pixmaps get refcnt incremented during I830DRI2CreateB
> 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 @@ I830DRI2Destroy
> DRI2BufferPtr
> buffers, int count)
> {
> ScreenPtr pScreen = pDraw->pScreen;
> I830DRI2BufferP
> + PixmapPtr pDepthPixmap = NULL;
> int i;
>
> for (i = 0; i < count; i++)
> {
> private = buffers[
> + if (buffers[
> + buffers[
> + private-
> + }
> +
> + if (buffers[
> + pDepthPixmap = private->pPixmap;
> +
> (*pScreen-
> }
>
>
> --
> Configure bugmail: http://
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug.
>

|
#40 |
I've tried following configuration of codes:
Kernel_version: 2.6.29.1
Libdrm: (master)
Mesa: (mesa_7_
Xserver: (server-
Xf86_video_intel: (2.7)296a986e52
Kernel: (qa-branch)
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

|
#41 |
Shuang He,
With your patch, when I start compiz, X crashes:
Backtrace:
0: /usr/X11R6/
1: /usr/X11R6/bin/X [0x431e3d]
2: /lib/libpthread
3: /usr/lib/
4: /usr/lib/
5: /usr/lib/
[0x7f6aa609827e]
6: /usr/lib/
7: /usr/X11R6/bin/X [0x48e8e4]
8: /usr/X11R6/bin/X [0x42951d]
9: /lib/libc.
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)
mesa: (master)
xserver: (master)
xf86-video-intel: (master)
On Fri, Apr 24, 2009 at 5:56 AM, <email address hidden> wrote:
> http://
>
>
>
>
>
> --- 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)
> Mesa: (mesa_7_
> Xserver: (server-
> Xf86_video_intel:
> (2.7)296a986e52
> Kernel: (qa-branch)
>
> 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://
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug.
>

|
#42 |
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/
> 1: /usr/X11R6/bin/X [0x431e3d]
> 2: /lib/libpthread
> 3: /usr/lib/
> 4: /usr/lib/
> 5: /usr/lib/
> [0x7f6aa609827e]
> 6: /usr/lib/
> 7: /usr/X11R6/bin/X [0x48e8e4]
> 8: /usr/X11R6/bin/X [0x42951d]
> 9: /lib/libc.
> 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)
> mesa: (master)
> xserver: (master)
> xf86-video-intel: (master)
>
>
> On Fri, Apr 24, 2009 at 5:56 AM, <email address hidden> wrote:
>
> > http://
> >
> >
> >
> >
> >
> > --- 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)
> > Mesa: (mesa_7_
> > Xserver: (server-
> > Xf86_video_intel:
> > (2.7)296a986e52
> > Kernel: (qa-branch)
> >
> > 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://
> > ------- You are receiving this mail because: -------
> > You are on the CC list for the bug.
> >
>

|
#43 |
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/
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://
>
>
>
>
>
> --- 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/
> > 1: /usr/X11R6/bin/X [0x431e3d]
> > 2: /lib/libpthread
> > 3: /usr/lib/
> > 4: /usr/lib/
> > 5: /usr/lib/
> > [0x7f6aa609827e]
> > 6: /usr/lib/
> > 7: /usr/X11R6/bin/X [0x48e8e4]
> > 8: /usr/X11R6/bin/X [0x42951d]
> > 9: /lib/libc.
> > 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)
> > mesa: (master)
> > xserver: (master)
> > xf86-video-intel: (master)
> >
> >
> > On Fri, Apr 24, 2009 at 5:56 AM, <email address hidden>
> wrote:
> >
> > > http://
> > >
> > >
> > >
> > >
> > >
> > > --- 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)
> > > Mesa:
> (mesa_7_
> > > Xserver:
> (server-
> > > Xf86_video_intel:
> > > (2.7)296a986e52
> > > Kernel: (qa-branch)
> > >
> > > 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://...

|
#44 |
I already knew that my patch is not working.
With that configurations I mentioned in comment #36, __without_
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/
> 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) wrote : | #45 |
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) wrote : | #46 |
Start compiz with "compiz.real --replace --sm-disable --ignore-

|
#47 |
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-
Kernel -- (qa-branch)
Libdrm -- (master)
Mesa -- (mesa_7_
Xserver -- (server-
Xf86_video_intel -- (2.7)296a986e52

Ongion (benpy2k) wrote : | #48 |
Vitali, that fix causes some problems with transparency. The fix for a certain UXA transparency bug was to turn off indirect-rendering.

Ongion (benpy2k) wrote : | #49 |
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) wrote : | #50 |
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) wrote : | #51 |
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"
Driver "intel"
Option "AccelMethod" "EXA"
Option "MigrationHeuri
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) wrote : | #52 |
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"
Driver "intel"
Option "AccelMethod" "EXA"
Option "MigrationHeuri
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) wrote : | #53 |
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) wrote : | #54 |
@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-

|
#55 |
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.

|
#56 |
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_
**6022** shuang 443 alloc: handle=474, size=256 KB
==6022== at 0x5511171: VALGRIND_
==6022== by 0x5511CF8: drm_intel_
==6022== by 0x550D473: drm_intel_
==6022== by 0x52978AE: intel_region_alloc (intel_
==6022== by 0x52968A1: intel_miptree_
==6022== by 0x52B761B: intelTexImage (intel_
==6022== by 0x52B80CD: intelTexImage2D (intel_
==6022== by 0x5370B19: _mesa_TexImage2D (teximage.c:2676)
==6022== by 0x45A021D: (within /usr/lib/
==6022== by 0x45A04E8: cogl_texture_
==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_
==6022== by 0x551131E: drm_intel_
==6022== by 0x55112AD: drm_intel_
==6022== by 0x55112AD: drm_intel_
==6022== by 0x5511791: drm_intel_
==6022== by 0x550D4B5: drm_intel_
==6022== by 0x52D0B2A: brw_clear_cache (brw_state_
==6022== by 0x52D8C8C: brw_note_unlock (brw_vtbl.c:184)
==6022== by 0x528C43B: UNLOCK_HARDWARE (intel_
==6022== by 0x52C58EA: brw_draw_prims (brw_draw.c:417)
==6022== by 0x538E59B: vbo_exec_
==6022== by 0x5382EB9: neutral_
If I reduced the limit of cached items, this symptom will disappear:
diff --git a/src/mesa/
index e40d7a0..0afb7af 100644
--- a/src/mesa/
+++ b/src/mesa/
@@ -527,10 +527,10 @@ brw_state_ca...

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

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

|
#59 |
(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:
glXReleaseTexIm

|
#60 |
Created an attachment (id=26328)
glXReleaseTexIm
reupload

|
#61 |
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 glXDestroyGLXPi

Sebastian Rühl (sebastian-ruehl) wrote : | #62 |
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/
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) wrote : | #63 |
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.

|
#64 |
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 glXDestroyGLXPi
> 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/
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.

|
#65 |
(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 glXDestroyGLXPi
> > 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/
> 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.

|
#66 |
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)
Mesa (master)
Xserver (master)
Xf86_video_intel (master)
Kernel (for-linus)

|
#67 |
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.

|
#68 |
Perhaps I should also mention that I pulled Eric Anholt's drm branch from git://git.
which contains quite a few changes, and I am using latest git now.

|
#69 |
(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: d027e8feff7d38c
Thanks for your work Shuang
Changed in compiz: | |
status: | Confirmed → Fix Released |

Jason Smith (jassmith) wrote : | #70 |
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

|
#71 |
Verified

Sebastian Rühl (sebastian-ruehl) wrote : | #72 |
is there a fixed package for compiz available?

Petar Velkovski (pvelkovski) wrote : | #73 |
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_
and changed it into:
COMPIZ_
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:/

Sebastian Rühl (sebastian-ruehl) wrote : | #74 |
is use the 2:2.7.1-
I will give that option a try. But what exactly happens when I enable --indirect-

Sebastian Rühl (sebastian-ruehl) wrote : | #75 |
sorry. I have forgotten to mention that; I have kms enabled

Petar Velkovski (pvelkovski) wrote : | #76 |
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) wrote : | #77 |
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) wrote : | #78 |
I can't remember currently where I found this but you need to do following:
create a file /etc/modprobe.
and insert this content. :
options i915 modeset=1
this should be all...

Alexandros (alexandros-t) wrote : | #79 |
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) wrote : | #80 |

Alexandros (alexandros-t) wrote : | #81 |
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-

mehturt (mehturt) wrote : | #82 |
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) wrote : | #83 |
I found a symptom of the memory leak:
Type on a terminal this command:
watch -n 1 cat /proc/dri/
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) wrote : | #84 |
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) wrote : | #85 |
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) wrote : | #86 |
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) wrote : | #87 |
I've just tested with EXA:
alexandros@
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-

Sebastian Rühl (sebastian-ruehl) wrote : | #88 |
this bug is a real pain...
Im running a 64bit Jaunty on a X61T with this driver 2:2.7.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) wrote : | #89 |
i'm on 2.8.0+git200907

Travis Watkins (amaranth) wrote : | #90 |
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) wrote : | #91 |
Same problem here, full memory, full swap, almost frozen machine.
I am running ubuntu jaunty with 2.6.30 kernel.

Petar Velkovski (pvelkovski) wrote : | #92 |
garijon have you tried my suggestion at #17?

Sebastian Rühl (sebastian-ruehl) wrote : | #93 |
@Petar
I tried it like you suggested but the leak still occurs...

garijon (garijon) wrote : Re: [Bug 328232] Re: [Jaunty][UXA]compiz.real memory leak | #94 |
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]
> https:/
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Petar Velkovski (pvelkovski) wrote : | #95 |
I doubt this will be fixed soon.
Just for a reference this is the package sources I use:
deb http://
deb-src http://
deb http://
deb-src http://
deb http://
deb-src http://
deb http://
deb-src http://
deb http://
deb http://
deb-src http://
deb http://
deb-src http://
deb http://
deb-src http://
deb http://
deb http://
deb http://
deb http://
deb http://
deb http://
deb http://
deb http://
deb http://
deb http://
deb http://
deb http://
(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/
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) wrote : | #96 |
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://
comment #5
I'm having this bug in jaunty with kde 4.3
Intel GMA x3100. (GM965)

Travis Watkins (amaranth) wrote : | #97 |
This is fixed in the compiz packages in karmic.
Changed in compiz (Ubuntu): | |
status: | Confirmed → Fix Released |

STaRMaN (jarizaro) wrote : | #98 |
Could someone build/say the fix for Jaunty?
Thanks
Changed in compiz: | |
importance: | Unknown → High |
Changed in compiz: | |
importance: | High → Unknown |
Changed in compiz: | |
importance: | Unknown → High |
As discussed on the forum in this thread: http:// ubuntuforums. org/showthread. php?s=d0ff5aae2 47ab70c9a4cd20b 123a281e& 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.