From mboxrd@z Thu Jan  1 00:00:00 1970
Path: news.gmane.org!not-for-mail
From: Eli Zaretskii <eliz@gnu.org>
Newsgroups: gmane.emacs.devel
Subject: Re: Memory again
Date: Tue, 06 Dec 2011 08:12:51 -0500
Message-ID: <E1RXupH-000676-Tf@fencepost.gnu.org>
References: <CACY+Hvpan_AwucCt3=g6u=HKdxzN+QJ9xSTakKJW=kRetpqFig@mail.gmail.com>
	<4ED0F945.5090805@yandex.ru>
	<CACY+Hvo6Jn-4WG2j5B7pVHx8BmOk_QDykO6P2mUr6LXHkNm-GQ@mail.gmail.com>
	<83pqge7syw.fsf@gnu.org> <87mxb6tkji.fsf@wanadoo.es>
	<E1RXnGN-0005GW-To@fencepost.gnu.org>
	<CACY+HvqYHLa5d09SWkL-LqvRbuun3Wq78n8-Xki6XDXgoiVq1Q@mail.gmail.com>
Reply-To: Eli Zaretskii <eliz@gnu.org>
NNTP-Posting-Host: lo.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Trace: dough.gmane.org 1323177181 15793 80.91.229.12 (6 Dec 2011 13:13:01 GMT)
X-Complaints-To: usenet@dough.gmane.org
NNTP-Posting-Date: Tue, 6 Dec 2011 13:13:01 +0000 (UTC)
Cc: ofv@wanadoo.es, emacs-devel@gnu.org
To: Carsten Mattner <carstenmattner@googlemail.com>
Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Dec 06 14:12:57 2011
Return-path: <emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org>
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 <emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org>)
	id 1RXupN-0003x8-HA
	for ged-emacs-devel@m.gmane.org; Tue, 06 Dec 2011 14:12:57 +0100
Original-Received: from localhost ([::1]:48939 helo=lists.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org>)
	id 1RXupM-0006fW-ND
	for ged-emacs-devel@m.gmane.org; Tue, 06 Dec 2011 08:12:56 -0500
Original-Received: from eggs.gnu.org ([140.186.70.92]:35687)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <eliz@gnu.org>) id 1RXupJ-0006ck-IZ
	for emacs-devel@gnu.org; Tue, 06 Dec 2011 08:12:54 -0500
Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <eliz@gnu.org>) id 1RXupI-0005JI-Kp
	for emacs-devel@gnu.org; Tue, 06 Dec 2011 08:12:53 -0500
Original-Received: from fencepost.gnu.org ([140.186.70.10]:35649)
	by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@gnu.org>)
	id 1RXupI-0005JC-FS
	for emacs-devel@gnu.org; Tue, 06 Dec 2011 08:12:52 -0500
Original-Received: from eliz by fencepost.gnu.org with local (Exim 4.71)
	(envelope-from <eliz@gnu.org>)
	id 1RXupH-000676-Tf; Tue, 06 Dec 2011 08:12:51 -0500
In-reply-to: <CACY+HvqYHLa5d09SWkL-LqvRbuun3Wq78n8-Xki6XDXgoiVq1Q@mail.gmail.com>
	(message from Carsten Mattner on Tue, 6 Dec 2011 10:35:09 +0100)
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3)
X-Received-From: 140.186.70.10
X-BeenThere: emacs-devel@gnu.org
X-Mailman-Version: 2.1.14
Precedence: list
List-Id: "Emacs development discussions." <emacs-devel.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/emacs-devel>,
	<mailto:emacs-devel-request@gnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/archive/html/emacs-devel>
List-Post: <mailto:emacs-devel@gnu.org>
List-Help: <mailto:emacs-devel-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/emacs-devel>,
	<mailto:emacs-devel-request@gnu.org?subject=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:146502
Archived-At: <http://permalink.gmane.org/gmane.emacs.devel/146502>

> Date: Tue, 6 Dec 2011 10:35:09 +0100
> From: Carsten Mattner <carstenmattner@googlemail.com>
> Cc: Óscar Fuentes <ofv@wanadoo.es>, emacs-devel@gnu.org
> 
> Any ready-made instrumentation to reveal what's going on for find
> the root cause or explanation of what's going?

I'm not aware of any existing instrumentation.  Maybe someone else can
help.

Failing that, perhaps some tool that can show detailed memory usage
and allows to find, for each memory region, its corresponding C
symbol, could be used to find out which one(s) are holding on to the
supposedly free memory in your use case.