Re: Debugging emacs memory management

[Dima Kogan]

Eli Zaretskii <address@hidden> writes:

> 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.

Of course. We're on the same page. I'm not claiming anything more that
under the specific conditions on my box there's a leak. And yes, there's
no specific diagnosis yet, but the probing is getting us closer.



>> 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".
>
> I tried to reproduce this on my machine, but couldn't.  What I see is
> that the chain of calls you reported happens only once, when the first
> frame is created.  When I later create a second frame, either with
> "C-x 5 f" or by invoking emacsclient, x_new_font is indeed invoked
> again, but it doesn't call Fset_char_table_range, and consequently no
> additional sub-char-tables are allocated.
>
> So I guess your customizations, in particular those related to fonts
> and fontsets, are critical for debugging this problem.

My machine ran out of memory, tried to swap, locked up, and forced me to
reboot. When it came back, I no longer see the leak under THESE
conditions. However, the leak described in

  http://debbugs.gnu.org/cgi/bugreport.cgi?bug=21509

now happens even more readily than it did before, so I'm going to focus
on that now. Will post findings in that report.

Thanks for looking at this, Eli.