bug#21556: 25.0.50; Memory leak in emacs -Q with lucid (font)

[Dima Kogan]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Dima Kogan <dima@secretsauce.net>
>> Cc: Eli Zaretskii <eliz@gnu.org>, handa@gnu.org, 21556@debbugs.gnu.org
>> Date: Thu, 29 Oct 2015 15:51:38 -0700
>> 
>> Dmitry Antipov <dmantipov@yandex.ru> writes:
>> 
>> > On 10/01/2015 09:50 PM, Dima Kogan wrote:
>> >
>> >> OK, so are you suggesting changing how mark_face_cache() works? How bad
>> >> is it to accept that fonts and font entities are not necessarily linked,
>> >> and to install the latest patch in this bug?
>> >
>> > I'm suggesting to check whether there are unmarked font objects after 
>> > marking
>> > from Vfontset_table, and, if so, understand whether it's correct. Otherwise
>> > your patch, even being correct by itself, may just hide subtle GC bug.
>> 
>> Hi. I looked at this again. Running the same test as before (emacs -Q,
>> repeatedly creating/destroying client frame) I see:
>> 
>> 
>> - entities are created with each new client frame but are /never/
>>   marked.
>> 
>> - entity-creation backtrace is always
>> 
>>   #0  0x000000000060e74e in font_make_entity () at font.c:173
>>   #1  0x00000000006793ae in ftfont_pattern_entity (p=0xf8c180, 
>> extra=20784563) at ftfont.c:215
>>   #2  0x000000000067b952 in ftfont_list (f=0x13fb8c0, spec=13463989) at 
>> ftfont.c:1057
>>   #3  0x0000000000680de6 in xftfont_list (f=0x13fb8c0, spec=13463989) at 
>> xftfont.c:138
>>   #4  0x0000000000615ebc in font_list_entities (f=0x13fb8c0, spec=20978277) 
>> at font.c:2780
>>   #5  0x0000000000617c27 in font_find_for_lface (f=0x13fb8c0, 
>> attrs=0x7fff3ee81f50, spec=20082933, c=-1) at font.c:3262
>>   #6  0x0000000000617fb0 in font_load_for_lface (f=0x13fb8c0, 
>> attrs=0x7fff3ee81f50, spec=20082933) at font.c:3335
>>   #7  0x00000000006183a2 in font_open_by_spec (f=0x13fb8c0, spec=20082933) 
>> at font.c:3429
>>   #8  0x0000000000618415 in font_open_by_name (f=0x13fb8c0, name=13702436) 
>> at font.c:3440
>>   #9  0x000000000052fec4 in x_default_font_parameter (f=0x13fb8c0, 
>> parms=20784979) at xfns.c:2904
>>   #10 0x0000000000530bc2 in Fx_create_frame (parms=20784979) at xfns.c:3139
>> 
>> - Vfontset_table has fontsets and font-specs in it, but NO
>>   font-entities. Marking from the Vfontset_table thus cannot mark any
>>   font entities.
>> 
>> Where are the entities supposed to be referenced? Does it make sense
>> they're never marked?
>
> It's a long time since we last spoke about this, so maybe I've lost
> the focus.

I'm forgetting what's happening here too, so trying to finish this bug
now.


> We are discussing a problem with leaking memory, right? If
> font-entities are related to that, and if not marking them is the
> cause of the memory leak, then you are, in effect, saying that when we
> GC a font-entity, we should free some additional memory referenced by
> that font-entity, is that correct?

This isn't quite what's happening here. We have:

- fonts (sometimes) live inside font-entities

- before the patch in this report, the cache compaction code drops font
  entities that aren't marked from the cache

- I'm observing that such unmarked entities sometimes contain marked
  fonts. These become un-cached when their entity is dropped

- Fonts are eventually deallocated by traversing the cache, but these
  un-cached fonts are no longer in the cache, so they leak. So the
  entity isn't the thing that leaks, but fonts that were removed from
  the cache while still used.

- Patch in report looks at the fonts in the entity, and drops the entity
  only if the contained fonts are unmarked also

- Dmitry thinks that unmarked-fonts-inside-a-marked-entity is a
  situation that can't happen, so he requested a deeper look at this. In
  particular, he thinks that after marking from Vfontset_table,
  everything (fonts and entities) should be marked. My latest email was
  in reference to these questions.

Hope this is useful