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: Debugging emacs memory management
Date: Mon, 21 Sep 2015 13:00:45 +0300
Message-ID: <837fnknlbm.fsf@gnu.org>
References: <87zj8l3r32.fsf@secretsauce.net> <87vbbbxz2e.fsf@secretsauce.net>
	<55F998C8.4080203@cs.ucla.edu> <87vbb492ea.fsf@secretsauce.net>
	<83twqonub8.fsf@gnu.org> <87oagw885o.fsf@secretsauce.net>
Reply-To: Eli Zaretskii <eliz@gnu.org>
NNTP-Posting-Host: plane.gmane.org
X-Trace: ger.gmane.org 1442829991 29742 80.91.229.3 (21 Sep 2015 10:06:31 GMT)
X-Complaints-To: usenet@ger.gmane.org
NNTP-Posting-Date: Mon, 21 Sep 2015 10:06:31 +0000 (UTC)
Cc: eggert@cs.ucla.edu, emacs-devel@gnu.org
To: Dima Kogan <lists@dima.secretsauce.net>
Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Sep 21 12:06:14 2015
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 ([208.118.235.17])
	by plane.gmane.org with esmtp (Exim 4.69)
	(envelope-from <emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org>)
	id 1Zdxz8-0001WX-8I
	for ged-emacs-devel@m.gmane.org; Mon, 21 Sep 2015 12:06:10 +0200
Original-Received: from localhost ([::1]:57270 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 1Zdxz7-00088P-Gc
	for ged-emacs-devel@m.gmane.org; Mon, 21 Sep 2015 06:06:09 -0400
Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36734)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <eliz@gnu.org>) id 1Zdxyq-000884-Iu
	for emacs-devel@gnu.org; Mon, 21 Sep 2015 06:05:57 -0400
Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <eliz@gnu.org>) id 1Zdxyl-0005t6-S2
	for emacs-devel@gnu.org; Mon, 21 Sep 2015 06:05:52 -0400
Original-Received: from mtaout25.012.net.il ([80.179.55.181]:60784)
	by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@gnu.org>)
	id 1Zdxyl-0005sF-G5
	for emacs-devel@gnu.org; Mon, 21 Sep 2015 06:05:47 -0400
Original-Received: from conversion-daemon.mtaout25.012.net.il by mtaout25.012.net.il
	(HyperSendmail v2007.08) id
	<0NV000H00U9K5I00@mtaout25.012.net.il> for emacs-devel@gnu.org;
	Mon, 21 Sep 2015 12:57:36 +0300 (IDT)
Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout25.012.net.il
	(HyperSendmail v2007.08) with ESMTPA id
	<0NV0005PXUC0GUC0@mtaout25.012.net.il>;
	Mon, 21 Sep 2015 12:57:36 +0300 (IDT)
In-reply-to: <87oagw885o.fsf@secretsauce.net>
X-012-Sender: halo1@inter.net.il
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x
X-Received-From: 80.179.55.181
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:190184
Archived-At: <http://permalink.gmane.org/gmane.emacs.devel/190184>

> From: Dima Kogan <lists@dima.secretsauce.net>
> Cc: eggert@cs.ucla.edu, emacs-devel@gnu.org
> Date: Mon, 21 Sep 2015 01:54:11 -0700
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > This doesn't seem to be a leak in itself.
> 
> Hi. I'm fairly certain that this is the leak. I know I didn't show any
> evidence to that effect earlier, but I simply haven't written it up yet.
> Doing that now. Note that the attached scripts aren't particularly nice;
> they were quickly whipped up to solve a problem.

Thanks.  However, the data you collected does not yet allow to
identify the problem, let alone fix it.

> OK. So what are those 4k leaks? I follow all the 4k allocations with a
> follow_alloc.pl script. This acts as a filter to pull out the salient
> parts of the "script" file.
> 
>   <script ./follow_alloc.pl 4096 > follow4096
> 
> Looking at the follow4096 file I see that most of the 4k allocs have the
> backtrace in the previous email. None of these are ever freed. Some of
> the 4k allocs touch the menu stuff, and those are all freed (in
> garbage_collect, so the gc IS being called). Some of the 4k allocs are
> from the tool bar, and those all leak too, but there aren't as many of
> them as the font ones.
> 
> So this tells me that the backtrace in the previous email is the main
> one causing the leak. There's more stuff to look at however, like the
> toolbar stuff and a suspicious 16384 byte alloc, but those aren't as
> significant as this 4k one.

There's no need to try to prove there _is_ a leek in this scenario,
i.e. memory we allocate and don't free, because I believed you the
first time.  What is needed is not the _proof_ that a leak exists, but
detailed data that will allow to find out _why_ we leak memory.  And
that is only possible if you could present the arguments of the
functions and perhaps some other relevant values that are involved in
the suspect chain of calls.  Alternatively, a simple enough test case,
e.g. creating 2 frames one after another starting from "emacs -Q",
would allow us to walk through the relevant functions with a debugger
and see what's going on.

Please understand: when Emacs creates a new frame, there's any number
of calls to functions that end up allocating memory.  Unless we focus
on specific call chains, study their arguments, and determine why each
chunk of memory is allocated and how it is used, there's no hope for
us to efficiently find and fix this problem.

I will try to reproduce the problem on my machine; to help that,
please tell me (a) what font/fontset-related customizations do you
have, and (b) do you see the same problem when Emacs is started as
"emacs -Q".

Thanks.