[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#21556: 25.0.50; Memory leak in emacs -Q with lucid (font)
From: |
Dima Kogan |
Subject: |
bug#21556: 25.0.50; Memory leak in emacs -Q with lucid (font) |
Date: |
Fri, 30 Oct 2015 12:17:36 -0700 |
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
- bug#21556: 25.0.50; Memory leak in emacs -Q with lucid (font), Dima Kogan, 2015/10/03
- bug#21556: 25.0.50; Memory leak in emacs -Q with lucid (font), Dmitry Antipov, 2015/10/08
- bug#21556: 25.0.50; Memory leak in emacs -Q with lucid (font), Dima Kogan, 2015/10/08
- bug#21556: 25.0.50; Memory leak in emacs -Q with lucid (font), Dmitry Antipov, 2015/10/08
- bug#21556: 25.0.50; Memory leak in emacs -Q with lucid (font), Dima Kogan, 2015/10/08
- bug#21556: 25.0.50; Memory leak in emacs -Q with lucid (font), Dmitry Antipov, 2015/10/08
- bug#21556: 25.0.50; Memory leak in emacs -Q with lucid (font), Dima Kogan, 2015/10/08
- bug#21556: 25.0.50; Memory leak in emacs -Q with lucid (font), Dima Kogan, 2015/10/29
- bug#21556: 25.0.50; Memory leak in emacs -Q with lucid (font), Eli Zaretskii, 2015/10/30
- bug#21556: 25.0.50; Memory leak in emacs -Q with lucid (font),
Dima Kogan <=
- bug#21556: 25.0.50; Memory leak in emacs -Q with lucid (font), Eli Zaretskii, 2015/10/30
- bug#21556: 25.0.50; Memory leak in emacs -Q with lucid (font), Dima Kogan, 2015/10/30
bug#21556: 25.0.50; Memory leak in emacs -Q with lucid (font), Eli Zaretskii, 2015/10/08