GNU bug report logs - #21556
25.0.50; Memory leak in emacs -Q with lucid (font cache cleared prematurely)

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dima Kogan <dima <at> secretsauce.net>
Cc: handa <at> gnu.org, dmantipov <at> yandex.ru, 21556 <at> debbugs.gnu.org
Subject: bug#21556: 25.0.50; Memory leak in emacs -Q with lucid (font)
Date: Fri, 30 Oct 2015 16:20:01 +0200

> From: Dima Kogan <dima <at> secretsauce.net>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, handa <at> gnu.org, 21556 <at> debbugs.gnu.org
> Date: Thu, 29 Oct 2015 15:51:38 -0700
> 
> Dmitry Antipov <dmantipov <at> 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.  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?

If so, the problem is not that font-entities are not marked; that can
only explain why we GC some font-entities which we shouldn't have,
something that cannot possibly lead to a memory leak.  Any Lisp object
that is not marked will be GC'ed during the next GC cycle, so not
marking intermediary short-lived objects should be fine.  However, it
could be that when we GC them, we forget to free some related memory
that is not part of the font-entity object itself -- that could
certainly lead to a leak.

Does this make sense?  Or did I miss something?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.