[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Debugging emacs memory management

From: Dima Kogan
Subject: Re: Debugging emacs memory management
Date: Tue, 22 Sep 2015 14:33:55 -0700

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


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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]