From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Simon Josefsson Newsgroups: gmane.emacs.devel Subject: Re: Debugging memory leaks/stale references Date: Mon, 27 Sep 2004 22:48:27 +0200 Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Message-ID: References: <87d60fjzdg.fsf@deneb.enyo.de> <871xgnmree.fsf@deneb.enyo.de> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1096318260 30739 80.91.229.6 (27 Sep 2004 20:51:00 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 27 Sep 2004 20:51:00 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Sep 27 22:50:54 2004 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1CC2ST-0005ob-00 for ; Mon, 27 Sep 2004 22:50:53 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CC2Yh-0007aA-Su for ged-emacs-devel@m.gmane.org; Mon, 27 Sep 2004 16:57:19 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CC2Xf-0007CL-NB for emacs-devel@gnu.org; Mon, 27 Sep 2004 16:56:15 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CC2Xd-0007BF-IJ for emacs-devel@gnu.org; Mon, 27 Sep 2004 16:56:14 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CC2Xd-0007BC-Fy for emacs-devel@gnu.org; Mon, 27 Sep 2004 16:56:13 -0400 Original-Received: from [80.91.229.2] (helo=main.gmane.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CC2QV-00054D-BT for emacs-devel@gnu.org; Mon, 27 Sep 2004 16:48:51 -0400 Original-Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1CC2QU-0002oA-00 for ; Mon, 27 Sep 2004 22:48:50 +0200 Original-Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 27 Sep 2004 22:48:50 +0200 Original-Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 27 Sep 2004 22:48:50 +0200 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Original-To: emacs-devel@gnu.org Original-Lines: 53 Original-X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se Mail-Copies-To: nobody User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:tfNiLabJchxFF6gp0nNfyAocPKw= X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 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 Xref: main.gmane.org gmane.emacs.devel:27630 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:27630 Stefan Monnier writes: >> while they are traversed. Unfortunately, no major leak turned up, >> just a few thousand cons cells which can't cause the massive leak I >> see (in the order of dozens of megabytes after entering/exiting a >> large NNTP group with Gnus). > > I think it would be worthwhile to start with the basic info returned by > `garbage-collect' and such stuff. See `memory-usage.el' below. > [ I thought you already tried that, but the few lines above make me think > that you don't even know whether the extra MBs are made up of cons cells, or > strings, or non-elisp-data, or ...] Thanks, memory-usage seem useful. The memory growth caused by Gnus seem to escape it though. This is a fairly fresh emacs (I'm using Gnus, programming C and reading documentation, but nothing fancy): 20807 jas 15 0 365m 185m 17m S 2.7 18.3 89:12.64 emacs But there is no indication of where the memory is used (see below). Perhaps the "top" statistics aren't reliable, but the fact remains that the sluggishness I feel appear to be correlated to high memory usage according to "top". Hm. Is it possible to use 'gdb' to find out where all memory goes? Seems like it should have the capability to do it, at least. (FWIW, the above emacs is not sluggish.) Garbage collection stats: ((1130529 . 100249) (60991 . 170) (8108 . 5450) 3508516 1049895 (322 . 551) (34955 . 28764) (143989 . 25103)) => 9846224 bytes in cons cells 1467864 bytes in symbols 271160 bytes in markers 3508516 bytes of string chars 4199580 bytes of vector slots 10476 bytes in floats 1784132 bytes in intervals Total bytes in lisp objects (not counting string and vector headers): 17938267 Buffer ralloc memory usage: 147 buffers 5564167 bytes total (66581 in gaps) Size Gap Name 1843610 2000 *DOC* 524443 2000 snprintf_2.2.tar.gz 467401 2000 *Messages* 460876 2000 *Gnus Backlog* ...