Bug 28227

Can you see what is using all the memory?  Is it kwin?  The xserver?

X stays at 24mb RSS, kwin at 28mb RSS.
xrestop shows constantly ~30mb of pixmaps allocated.

Also the "used" memory stays the same, its only swap thats filling up although there's plenty of free ram available.

I remember having the same kind of problem with early intel drivers, after they switched to GEM. Problems were solved when they implemented some "shrinker logic", but to be honest I have no clue what this was all about ;)

(In reply to comment #2)
> X stays at 24mb RSS, kwin at 28mb RSS.
> xrestop shows constantly ~30mb of pixmaps allocated.
> 
> Also the "used" memory stays the same, its only swap thats filling up although
> there's plenty of free ram available.

So apparently it's not 'normal' memory leaking. Is the leak reflected in /proc/dri/0/gem_objects ?

Seems to, after resizing a few minutes gem_objects looks like:

[ce@cebox ~]$ cat /proc/dri/0/gem_objects 
4977 objects
-1432866816 object bytes
0 pinned
0 pin bytes
0 gtt bytes
0 gtt total

[ce@cebox ~]$ free
             total       used       free     shared    buffers     cached
Mem:       2061952    2008144      53808          0        528    1454268
-/+ buffers/cache:     553348    1508604
Swap:      2047992    1270176     777816


Disabling composition freed only a few gem_objects and ~100mb swap:

[ce@cebox ~]$ cat /proc/dri/0/gem_objects 
4272 objects
-1451466752 object bytes
0 pinned
0 pin bytes
0 gtt bytes
0 gtt total

By the way I am also experiencing problems with windows larger than ~2048px when composition is turned on. Should I file another bug about that?

Something seems to be leaking BOs.

Is the leak the same with kwin using direct or indirect rendering? With direct rendering, does the leak recover when killing kwin? In general, does it recover when the X server dies? ...

Only killing X recovers the memory.
Killing kwin doesn't help and direct/indirect rendering doesn't make a difference :/

Do you know which commit from server-1.8-branch your X server is based on exactly, and if it has any patches touching glx/ or hw/xfree86/dri2/?

(In reply to comment #4)
> By the way I am also experiencing problems with windows larger than ~2048px
> when composition is turned on. Should I file another bug about that?

The max texture and render target size on r2xx is 2048 pixels.  It's a hardware limitation.  GL apps should query the max texture size and not exceed it.

Its basically a stock Fedora 13

So another report dies siletly :/

(In reply to comment #10)
> So another report dies siletly :/

Clemens, this isn't free entertainment for you. ;) Please help us narrow down why you're seeing this bug while we aren't, e.g. by trying if it also happens with another compositing manager like compiz, or with current upstream components, ...

Also,

(In reply to comment #9)
> Its basically a stock Fedora 13

Is not sufficient information for an upstream report.

Hello

I have the same issue.

01:00.0 VGA compatible controller: ATI Technologies Inc RV280 [Radeon 9200] (rev 01)

It has 128Mb RAM onboard.

I'm using Gentoo and:

linux-2.6.38-r3
xorg-server-1.9.4 
libdrm-2.4.25
xf86-video-ati-6.14.1
mesa-7.10.2-r1

(In reply to comment #7)
> Do you know which commit from server-1.8-branch your X server is based on
> exactly, and if it has any patches touching glx/ or hw/xfree86/dri2/?

Seems no.

Any extra information?


Thanks.

Mass closure: This bug has been untouched for more than six years, and is not
obviously still valid. Please reopen this bug or file a new report if you continue to experience issues with current releases.