Re: Debugging emacs memory management

[Eli Zaretskii]

> From: Dima Kogan <address@hidden>
> Cc: address@hidden, address@hidden
> Date: Mon, 21 Sep 2015 01:54:11 -0700
> 
> Eli Zaretskii <address@hidden> 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.