Re: Debugging emacs memory management

[Dima Kogan]

Eli Zaretskii <address@hidden> writes:

>> From: Dima Kogan <address@hidden>
>> Cc: address@hidden, address@hidden
>> Date: Mon, 05 Oct 2015 01:24:08 -0700
>> 
>> > If so, please show the values of the 2 arguments to assoc_no_quit (in
>> > their Lisp form, as displayed by the "pp" command).
>> 
>> This is the crux of the problem. The font_spec is
>> 
>>   #<font-spec nil unknown DejaVu\ Sans\ Mono nil iso10646-1 normal normal 
>> normal 14 nil 100 0 ((:name . "monospace-10") (user-spec . "monospace-10"))>
>> 
>> The auto_fontset_alist has many entries, all with the same identical key:
>> 
>>   #<font-spec nil unknown DejaVu\ Sans\ Mono nil iso10646-1 normal normal 
>> normal 14 nil 100 0 ((:name) (user-spec . "monospace-10"))>
>
> Not sure if it's relevant, but on my system, neither
> auto_fontset_alist entries nor the value of font_spec have the
> (:name ...) element.  They do have user-spec, but no :name.  Perhaps
> try finding out where does that come from.  (Functions in fontset.el
> look like one possible place.)

OK. So the problem is that fontset_from_font() does

  Lisp_Object font_spec = copy_font_spec (font_object);

and then sets this font_spec as the key to the alist. However
copy_font_spec() is not a deep copy, and the caller to
fontset_from_font() ends up with references to internals of font_spec.
It then changes those internals, and ends up changing the key of the
auto_fontset_alist.

Specifically the (name . ...) cons cell is the one being shared. If
anybody cares, the backtrace of the reset of the :name is

    #0  0x000000000054cdad in XSETCDR (c=15185539, n=0) at lisp.h:1194
    #1  0x0000000000608d42 in font_put_extra (font=19160773, prop=5184, val=0) 
at font.c:732
    #2  0x000000000060f849 in font_clear_prop (attrs=0x7ffccea52c20, 
prop=FONT_SLANT_INDEX) at font.c:3044
    #3  0x0000000000509d69 in merge_face_vectors (f=0xf975d0, 
from=0x7ffccea52d20, to=0x7ffccea52c20, named_merge_points=0x0) at xfaces.c:2130
    #4  0x0000000000510790 in x_supports_face_attributes_p (f=0xf975d0, 
attrs=0x7ffccea52d20, def_face=0xebb2e0)
        at xfaces.c:4691
    #5  0x00000000005113cb in Fdisplay_supports_face_attributes_p 
(attributes=10113851, display=16348629)

but this seems hardly relevant. Making copy_font_spec() a deep copy
probably would resolve this. Trying that now.