Announcing Fedora 7 Test 2 (6.91)

[Tomasz Kłoczko]

Dnia 01-03-2007, czw o godzinie 14:01 -0500, Christopher Blizzard
napisał(a):
> That's Gecko, not the X server.  It has pretty aggressive image
> caching and stores the pixmaps on the server, not in its own memory.
> If you shut down that process and the X server returns to something
> sane it's not an X leak.  (It's even arguable that if it doesn't
> shrink it's still not an X leak but is a fragmented allocator, but
> that's another discussion.)

I don't think it is in not only gecko bug because after kill all gecko
applications amount of memory reserved by X server not back to start
amount. Also xrestop don't shows anything about allocated big amount of
memory on X server side for pixmaps.

I'm just kill on my system all gecko applications and amount of memory
used by X serwer drop down *only* from ~2.2GB to ~1.9GB. If it is not
ML .. OK. Anyone working on fix X server "fragmented allocator" or so ?

Also another fact: I have on my hands Sunray thin X terminal which uses
own X server and as long I use the same scenario (gecko application with
refreshing page) I never observe for example killing X session by some
symptoms like X server memory leaks (SunRay server it is Solaris 10U2).
X session on SunRay can be runed many days without even growing amount
of memory consumed by gecko application on X client side and X server on
Solaris side. This ML^H^Hfragmentation allocator bug not occurs probably
because Solaris uses older version of Xorg X server (without this nasty
bug) so probably shorter way fo fix this can be some regression tests
observation.
The same gecko application on remote Linux X server in my case can kills
my X session (OOM) in ~2 days (X server is runed on computer with 4GB
memory and 8GB swap).

So IMO it is definitely something wrong on X server side. Even it it is
not my question stays ..  Q: anyone working on fix this ?

kloczek