Date: Fri, 04 Jan 2008 09:55:27 -0500 From: Coleman Kane <cokane@FreeBSD.org> To: x11@freebsd.org Subject: Re: Xorg memory leak Message-ID: <477E48DF.9060104@FreeBSD.org> In-Reply-To: <20080104075037.GA25510@demeter.hydra> References: <477BBB39.6070208@FreeBSD.org> <20080102182923.GM903@server.vk2pj.dyndns.org> <477C1750.9050506@FreeBSD.org> <20080103184014.GP947@server.vk2pj.dyndns.org> <20080104075037.GA25510@demeter.hydra>
next in thread | previous in thread | raw e-mail | index | archive | help
Chad Perrin wrote: > On Fri, Jan 04, 2008 at 05:40:14AM +1100, Peter Jeremy wrote: > >> On Wed, Jan 02, 2008 at 05:59:28PM -0500, Coleman Kane wrote: >> >>> It seems that while my terminal window remains relatively small (around >>> 80x30 characters), there doesn't seem to be any impact. However, if I >>> drag the window border to expand the size of it (to like 220x70 or >>> something), then it starts to chew up memory from the Xorg process. It >>> can sometimes get so bad as to take ~100MB per second at times. Normal >>> xterm does not seem to exhibit this behavior. One thing that I've >>> noticed is that the memory-eating seems to coincide with the point where >>> the gnome-terminal window's redraw rate starts to lag from the window >>> being far too large. >>> >> That's an interesting comment. Does gnome-terminal have any equivalent >> to the '+s' (synchronous) option on xterm and, if so, does that have any >> effect? >> >> >>> It won't go back down until Xorg is actually closed. >>> >> I think this implies that it's a bug in the X server because otherwise >> the resources would be released when the offending client is closed. >> > > Actually . . . since GNOME is basically just a bunch of shared libraries > plus glue code, most of which are apparently loaded into RAM at any given > time, it's entirely possible it's a GNOME problem. > > I oversimplify, but I think you get the gist. > If that were the case, those shared libraries and glue code would be linked into various GNOME processes, increasing their footprints (which does happen too), but then that memory would be freed upon exiting those programs. In this case, I am seeing a consistent growth of the memory footprint of the Xorg process, which leads me to believe that something is telling Xorg to allocate large quantities of RAM, but then Xorg does not release these until *it* exits. I assume that whatever is allocating space inside of Xorg is also supposed to have a corresponding free() call, and perhaps this is not being done. I would expect Xorg, however, to be able to track this information according to client socket handles, and automatically free() when the client that requested these allocations disconnects. In addition, xrestop is (from my understanding) *supposed to* be able to track these allocation requests, but it doesn't seem to be doing that. AFAICT, gnome-terminal uses x11-toolkits/vte to actually do the work of the Terminal inside of its window (including rendering). The vte library can use GLX/DRI for rendering (which I have disabled since radeonhd doesn't support it yet), and it uses gtk20, gdk-pixbuf2 (part of gtk20), and pango for rendering. I would imagine that somewhere in here lies the calls that create the problem. Now, I guess the question is whether or not the problem is caused by Xorg or by GNOME. I was able to recreate the problem easily with gnome-terminal, but I also said that Firefox and Thunderbird seem to produce the same problem (triggered by doing workspace switching), but they can't be made to grow the size of the Xorg process as quickly as gnome-terminal does. I can kill thunderbird, firefox, and gnome-terminal (and gnome-pty-helper), but the Xorg process doesn't release the memory until it is exited as well. -- Coleman Kane
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?477E48DF.9060104>