From owner-freebsd-x11@FreeBSD.ORG Fri Jan 4 14:56:48 2008 Return-Path: Delivered-To: x11@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8271416A418 for ; Fri, 4 Jan 2008 14:56:48 +0000 (UTC) (envelope-from cokane@freebsd.org) Received: from QMTA03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [76.96.30.32]) by mx1.freebsd.org (Postfix) with ESMTP id 62D2413C465 for ; Fri, 4 Jan 2008 14:56:48 +0000 (UTC) (envelope-from cokane@freebsd.org) Received: from OMTA13.emeryville.ca.mail.comcast.net ([76.96.30.52]) by QMTA03.emeryville.ca.mail.comcast.net with comcast id YzpA1Y00317UAYk0A0Co00; Fri, 04 Jan 2008 14:56:48 +0000 Received: from discordia ([24.60.136.97]) by OMTA13.emeryville.ca.mail.comcast.net with comcast id Z2wb1Y00926FYqY8Z00000; Fri, 04 Jan 2008 14:56:36 +0000 X-Authority-Analysis: v=1.0 c=1 a=0Ug3NM6OGaJI20sXR-EA:9 a=KXxhufJTwf220XnfRbcA:7 a=Az81IGUcv4xCvutGSQNprIOzECkA:4 a=C35D7iIojSgA:10 Received: by discordia (Postfix, from userid 103) id 1204D1634F7; Fri, 4 Jan 2008 09:56:47 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 3.1.8-gr1 (2007-02-13) on discordia X-Spam-Level: X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.8-gr1 Received: from [172.20.1.3] (erwin.int.cokane.org [172.20.1.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by discordia (Postfix) with ESMTP id A28491634F6 for ; Fri, 4 Jan 2008 09:56:32 -0500 (EST) Message-ID: <477E48DF.9060104@FreeBSD.org> Date: Fri, 04 Jan 2008 09:55:27 -0500 From: Coleman Kane Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.9 (X11/20071116) MIME-Version: 1.0 To: x11@freebsd.org 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> In-Reply-To: <20080104075037.GA25510@demeter.hydra> X-Enigmail-Version: 0.96a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: Xorg memory leak X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: cokane@FreeBSD.org List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 14:56:48 -0000 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