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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
