From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Carsten Mattner Newsgroups: gmane.emacs.devel Subject: Re: Pretest note Date: Tue, 13 Mar 2012 10:16:27 +0100 Message-ID: References: <87lin6zf2x.fsf@gnu.org> <87boo16mrn.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1331630211 10876 80.91.229.3 (13 Mar 2012 09:16:51 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 13 Mar 2012 09:16:51 +0000 (UTC) Cc: emacs-devel@gnu.org To: Chong Yidong Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Mar 13 10:16:50 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1S7NqX-0003Ui-Lc for ged-emacs-devel@m.gmane.org; Tue, 13 Mar 2012 10:16:45 +0100 Original-Received: from localhost ([::1]:41111 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S7NqW-0003Qg-Q3 for ged-emacs-devel@m.gmane.org; Tue, 13 Mar 2012 05:16:44 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:49353) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S7NqT-0003QJ-AJ for emacs-devel@gnu.org; Tue, 13 Mar 2012 05:16:42 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S7NqM-0002c9-HQ for emacs-devel@gnu.org; Tue, 13 Mar 2012 05:16:40 -0400 Original-Received: from mail-iy0-f169.google.com ([209.85.210.169]:59079) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S7NqH-0002az-Vp; Tue, 13 Mar 2012 05:16:30 -0400 Original-Received: by iajr24 with SMTP id r24so643919iaj.0 for ; Tue, 13 Mar 2012 02:16:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=6TE0eUjfU+Dg3+aU8H6oulwKqUrdjvH1+/zsguuSzKo=; b=khMqUfSqKUVuB/uOOatsv+ScaBuBg0ouGHujRYV37deYcauyN8mP18gMlcxlErqAzK TcWHqKsuYAf+KxBujdI0jfQPKR62xf7m0Zik9GEud+yXT4g4btfHhbgvgoNCGPa8lfx4 zUO6D3bogNgrWR2dIws52fY6/SLt/VTEAEv4Y+2K81+suK2bguBpzNSO1Jz4SQ7X50YN Z/QIV+hpCg7dXagScYd1AbShlPX1cikJkm1x/0ncI0oVjQ4qryOX8+OHwaycD8L3crFD j8m0H/O4nTVI0diijHCkGl0q827pMCsdj3nglwC/NF12DpEKR6wqZxkVyv8Yju0l9CqS 8wqA== Original-Received: by 10.42.167.194 with SMTP id t2mr1740044icy.40.1331630187444; Tue, 13 Mar 2012 02:16:27 -0700 (PDT) Original-Received: by 10.50.111.132 with HTTP; Tue, 13 Mar 2012 02:16:27 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 209.85.210.169 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:149002 Archived-At: On Tue, Mar 13, 2012 at 10:02 AM, Carsten Mattner wrote: > On Tue, Mar 13, 2012 at 7:25 AM, Chong Yidong wrote: >> Carsten Mattner writes: >> >>> Don't we want to do something about the leak(s) or at least verify >>> down that they're correct "caching" or "reuse" behavior? >> >> AFAICT, this is Jan's report that memory is not returned to the system >> on Mac OS? =A0Obviously, if someone can help pin this down, that will be >> appreciated. =A0Yamamoto Mitsuharu gave one suggestion here: > > While Jan was able to fix some obvious Cocoa issues and crashes, > this is not a Mac OS specific problem. I see the same extensive > non-reclaimed memory growth on Linux in both the X and terminal > client. > >> http://lists.gnu.org/archive/html/emacs-devel/2012-01/msg00358.html. >> >> Also, I'd like to know whether it really involves memory not being >> returned at all, independently of gnutls and networking. =A0For example, > > No network or gnutls use in any of my Linux and OS X builds. > > config options on Linux: > --without-selinux --without-tiff \ > =A0 =A0--without-sound --without-dbus --without-gconf \ > =A0 =A0--without-gsettings --without-xft --without-gsettings \ > =A0 =A0--without-jpeg --without-gif --without-gpm \ > =A0 =A0--with-x-toolkit=3Dno --without-gnutls" > > config options on Mac OS (to force building a 32-bit binary): > CFLAGS=3D$CFLAGS CC=3D'gcc -arch i386' ./configure --with-ns --without-gn= utls > > Maybe I should also disable xml2 and png as those might be enabled. > >> here is some Elisp code that visits a file and kills the buffer a few >> thousand times: >> >> (dotimes (n 50000) >> =A0(with-temp-buffer >> =A0 =A0(insert-file-contents "/path/to/emacs/etc/NEWS"))) >> >> If Emacs on Mac OS really never returns memory, this should chew up all >> the memory on your system. =A0Does it? =A0Check also if Emacs 23 is >> affected. > > If and only if that usage pattern is at fault, yes. I'll give it a try. Let's not forget that I'd like to use --daemon, but that's not practical as long as I don't have more physical memory or the leak is plugged. If we don't find the problem, I'm not insisting on delaying the release for me personally. I'm fine tracking bzr and restarting Emacs on an hourly basis to try one of the two daily rebuilds. I'm used to it. A shorter release cycle would remove the pressure, especially as most users seem to have enough physical memory to not care about the leak or fast enough machines to live with the cc-mode performance regressions. More users should ideally equal more testers and more useful feedback. Chong, thanks for taking this seriously and writing it off as ghosts seen by a couple users.