From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?iso-8859-1?Q?Jan_Dj=E4rv?= Newsgroups: gmane.emacs.devel Subject: Re: Memory again Date: Thu, 22 Dec 2011 20:15:10 +0100 Message-ID: <2AB13C59-F3BE-45F7-8C24-C88AA9AC8929@swipnet.se> References: <71677AF5-0EE7-426E-B8FA-C2782B3CC36C@swipnet.se> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1324581334 8318 80.91.229.12 (22 Dec 2011 19:15:34 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 22 Dec 2011 19:15:34 +0000 (UTC) Cc: emacs-devel@gnu.org To: emacs user Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Dec 22 20:15:28 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 1Rdo6x-0005Ry-1y for ged-emacs-devel@m.gmane.org; Thu, 22 Dec 2011 20:15:27 +0100 Original-Received: from localhost ([::1]:49944 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rdo6q-0004kY-2r for ged-emacs-devel@m.gmane.org; Thu, 22 Dec 2011 14:15:20 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:47679) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rdo6m-0004kO-Do for emacs-devel@gnu.org; Thu, 22 Dec 2011 14:15:17 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rdo6k-0003Zj-2N for emacs-devel@gnu.org; Thu, 22 Dec 2011 14:15:16 -0500 Original-Received: from mailout.melmac.se ([62.20.26.67]:49784) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rdo6j-0003YD-6h for emacs-devel@gnu.org; Thu, 22 Dec 2011 14:15:13 -0500 Original-Received: from mail01.melmac.se (mail01.melmac.se [62.20.26.80]) by mailout.melmac.se (Postfix) with ESMTP id 88385AC7E for ; Thu, 22 Dec 2011 20:15:10 +0100 (CET) Original-Received: (qmail 6745 invoked by uid 89); 22 Dec 2011 19:14:26 -0000 Original-Received: from h-46-59-42-18.na.cust.bahnhof.se (HELO coolsville.localdomain) (boel.djarv@bdtv.se@46.59.42.18) by mail01.melmac.se with ESMTPA; 22 Dec 2011 19:14:26 -0000 Original-Received: from [172.20.199.13] (zeplin [172.20.199.13]) by coolsville.localdomain (Postfix) with ESMTPSA id F0DB27FA058; Thu, 22 Dec 2011 20:15:09 +0100 (CET) In-Reply-To: X-Mailer: Apple Mail (2.1251.1) X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-Received-From: 62.20.26.67 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:146927 Archived-At: Hello. Is this only when you use vm? I think gnutls had some leaks, did you = link with that? Other than running valgrind on temacs, load everything in and then print = out reachable memory, I don't know how to check this. It sounds as it isn't a leak as such, but something that is still = referenced, but not needed. Jan D. 22 dec 2011 kl. 19:54 skrev emacs user: > 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: >>>=20 >>> 21 dec 2011 kl. 18:55 skrev emacs user: >>>=20 >>>>=20 >>>> Thanks... The leaks command indeed reports zero leaks now. = however, >>>> emacs still grows every time I invoke vm. here is a memory report >>>> which I get after killing all buffers, when emacs is 214 Mb large = (as >>>> seen in the Activity Monitor). is this normal? >>>>=20 >>>=20 >>> As I'm not a vm-user I can't really say. But it sounds like = something is not released back to the OS. >>>=20 >>> Jan D. >>=20 >> how does one go about diagnosing this? is it possible to tell if = this >> an elisp problem or a c-problem? >=20 > Just in case this is helpful in diagnosing this: > - The problem (rapidly growing memory and eventual crash) occurs also > with emacs -nw on mac os x. > - I tested, and as far as I can tell, this does not occur under = GNU/Linux >=20 >=20 >>>> Garbage collection stats: >>>> ((400287 . 303593) (45615 . 144) (60632 . 80546) 2488080 600138 = (708 . >>>> 477) (521 . 271) (85624 . 67826)) >>>>=20 >>>> =3D> 6404592+4857488 bytes in cons cells >>>> 2189520+6912 bytes in symbols >>>> 2425280+3221840 bytes in markers >>>> 11328+7632 bytes in floats >>>> 29176+15176 bytes in intervals >>>> 2739968+2170432 bytes in string headers >>>> 2488080 bytes of string chars >>>> 2488080 bytes of vector slots >>>>=20 >>>> Total bytes in lisp objects: 27167562 (live 16888082, dead = 10279480) >>>>=20 >>>> Buffer ralloc memory usage: >>>> 14 buffers >>>> 29463 bytes total (24346 in gaps) >>>> Size Gap Name >>>>=20 >>>> 2186 987 *srecode-map-tmp* >>>> 2186 1814 *code-converting-work* >>>> 565 1570 *Buffer Details* >>>> 170 1851 *Deletions* >>>> 30 2000 *Messages* >>>> 25 2019 *extract address components* >>>> 22 2022 *canonical address* >>>> 16 5812 *code-conversion-work* >>>> 11 2040 *Echo Area 1* >>>> 0 2022 *Minibuf-1* >>>> 0 20 *vm-nonexistent-summary* >>>> 0 20 *Minibuf-0* >>>> 0 2055 *Echo Area 0* >>>> 0 20 *subst-char-in-string* >>>=20