From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Florian Weimer Newsgroups: gmane.emacs.devel Subject: Re: Debugging memory leaks/stale references Date: Mon, 27 Sep 2004 22:36:23 +0200 Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Message-ID: <87mzzb30vs.fsf@deneb.enyo.de> 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 1096317451 28344 80.91.229.6 (27 Sep 2004 20:37:31 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 27 Sep 2004 20:37:31 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Sep 27 22:37:19 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 1CC2FL-0004X7-00 for ; Mon, 27 Sep 2004 22:37:19 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CC2La-0003Ub-Pq for ged-emacs-devel@m.gmane.org; Mon, 27 Sep 2004 16:43:46 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CC2L4-0003KT-RY for emacs-devel@gnu.org; Mon, 27 Sep 2004 16:43:15 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CC2L1-0003K8-UG for emacs-devel@gnu.org; Mon, 27 Sep 2004 16:43:13 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CC2L1-0003K2-Dc for emacs-devel@gnu.org; Mon, 27 Sep 2004 16:43:11 -0400 Original-Received: from [212.9.189.167] (helo=mail.enyo.de) by monty-python.gnu.org with esmtp (TLSv1:RC4-SHA:128) (Exim 4.34) id 1CC2EV-0002r5-A7 for emacs-devel@gnu.org; Mon, 27 Sep 2004 16:36:27 -0400 Original-Received: (debugging) helo=deneb.enyo.de ip=212.9.189.171 name=deneb.enyo.de Original-Received: from deneb.enyo.de ([212.9.189.171]) by mail.enyo.de with esmtp id 1CC2ET-0002Rb-7C; Mon, 27 Sep 2004 22:36:25 +0200 Original-Received: from fw by deneb.enyo.de with local (Exim 4.34) id 1CC2ER-0001jx-Ul; Mon, 27 Sep 2004 22:36:23 +0200 Original-To: Stefan Monnier In-Reply-To: (Stefan Monnier's message of "Mon, 27 Sep 2004 15:52:06 -0400") 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:27626 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:27626 * Stefan Monnier: > 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 ...] Others already did this. But thanks anyway, I repeated the experiment: The numbers indeed lack any distinct increase in magnitude. 8-( >> Are there any other objects that can change their size after >> allocation? (I'm pretty sure that there are no additional Lisp >> objects allocated, but maybe an existing object grows without bounds.) > > Yes. Things like the specpdl "stack", the matrices used in display, maybe > the text-property-tree nodes, ... Hmm, I'm going to gather a few more stats. (And running Emacs under valgrind could prove helpful because I could determine if the low-level allocator leaks memory.)