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: Memory again Date: Fri, 23 Dec 2011 00:09:24 +0100 Message-ID: References: <71677AF5-0EE7-426E-B8FA-C2782B3CC36C@swipnet.se> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1324595377 4778 80.91.229.12 (22 Dec 2011 23:09:37 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 22 Dec 2011 23:09:37 +0000 (UTC) Cc: =?ISO-8859-1?Q?Jan_Dj=E4rv?= , emacs-devel@gnu.org To: emacs user Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Dec 23 00:09:31 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RdrlS-0006fn-5Z for ged-emacs-devel@m.gmane.org; Fri, 23 Dec 2011 00:09:30 +0100 Original-Received: from localhost ([::1]:57933 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RdrlR-0004MX-M6 for ged-emacs-devel@m.gmane.org; Thu, 22 Dec 2011 18:09:29 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:53890) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RdrlP-0004MP-0u for emacs-devel@gnu.org; Thu, 22 Dec 2011 18:09:27 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RdrlN-0002s9-Sj for emacs-devel@gnu.org; Thu, 22 Dec 2011 18:09:26 -0500 Original-Received: from mail-iy0-f169.google.com ([209.85.210.169]:32968) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RdrlN-0002rs-Oh for emacs-devel@gnu.org; Thu, 22 Dec 2011 18:09:25 -0500 Original-Received: by iacb35 with SMTP id b35so14682158iac.0 for ; Thu, 22 Dec 2011 15:09:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=EiAXjSJVAxNrSCP2xEisTm98xkmYxztLBsgOL0dwNPQ=; b=uWqVclGtCeuSKAgjHxNl3UyrlON+0fHKZIXaMV1E6iGTCo4AXq6VkZj6HjXHWzYVg2 0ykrNLFsCSN1fSZOOWOXh1hL3ZrR2ptAj3SDPn3H5wLr0qj0py3yvQcC+eLioO/uonaq s+VwYNhgZFjjXxk1iRsZz+wVAuimghlil2pws= Original-Received: by 10.50.189.194 with SMTP id gk2mr10814312igc.0.1324595364556; Thu, 22 Dec 2011 15:09:24 -0800 (PST) Original-Received: by 10.50.6.165 with HTTP; Thu, 22 Dec 2011 15:09:24 -0800 (PST) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) 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:146929 Archived-At: On Thu, Dec 22, 2011 at 7:54 PM, emacs user wrote: > On Thu, Dec 22, 2011 at 4:58 PM, emacs user wrote: >> On Thu, Dec 22, 2011 at 4:08 PM, Jan Dj=E4rv wrote: >>> >>> 21 dec 2011 kl. 18:55 skrev emacs user: >>> >>>> >>>> Thanks... =A0The leaks command indeed reports zero leaks now. =A0howev= er, >>>> emacs still grows every time I invoke vm. =A0here is a memory report >>>> which I get after killing all buffers, when emacs is 214 Mb large (as >>>> seen in the Activity Monitor). =A0 is this normal? >>>> >>> >>> As I'm not a vm-user I can't really say. =A0But it sounds like somethin= g is not released back to the OS. >>> >>> =A0 =A0 =A0 =A0Jan D. >> >> how does one go about diagnosing this? =A0is it possible to tell if this >> an elisp problem or a c-problem? > > Just in case this is helpful in diagnosing this: > =A0- The problem (rapidly growing memory and eventual crash) occurs also > with emacs -nw on mac os x. > =A0- I tested, and as far as I can tell, this does not occur under GNU/Li= nux I can second that. Even without GnuTLS or gnus/vm issues. I only have to load a couple trivial and small source code buffers, nuke al= l buffers and wait for hours. No memory given back.