bug-gnu-emacs
[Top][All Lists]
Advanced

[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: Eli Zaretskii
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@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.  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?





reply via email to

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