From: Eli Zaretskii <eliz@gnu.org>
To: Dima Kogan <dima@secretsauce.net>
Cc: dmantipov@yandex.ru, 21556@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 [thread overview]
Message-ID: <83wpu4zbe6.fsf@gnu.org> (raw)
In-Reply-To: <87r3kdguf9.fsf@secretsauce.net>
> 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?
next prev parent reply other threads:[~2015-10-30 14:20 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-25 0:05 bug#21556: 25.0.50; Memory leak in emacs -Q with lucid (font) Dima Kogan
2015-09-25 6:45 ` Eli Zaretskii
2015-09-25 6:57 ` Dima Kogan
2015-09-25 8:44 ` Eli Zaretskii
2015-09-25 8:13 ` Dima Kogan
2015-09-25 8:49 ` Eli Zaretskii
2015-09-25 9:10 ` Eli Zaretskii
2015-09-25 9:30 ` Dima Kogan
2015-09-25 9:45 ` Eli Zaretskii
2015-09-25 10:03 ` Eli Zaretskii
[not found] ` <83y4ftfbjw.fsf@gnu.org>
2015-09-27 7:56 ` K. Handa
2015-09-27 8:09 ` Eli Zaretskii
2015-09-28 9:22 ` Dima Kogan
2015-09-28 9:58 ` Eli Zaretskii
2015-09-29 9:28 ` Dima Kogan
2015-09-30 7:00 ` Eli Zaretskii
2015-09-30 10:16 ` Dmitry Antipov
2015-10-01 9:42 ` Dima Kogan
2015-10-01 13:27 ` Dmitry Antipov
2015-10-01 18:50 ` Dima Kogan
2015-10-02 5:04 ` Dmitry Antipov
2015-10-02 18:56 ` Dima Kogan
2015-10-29 22:51 ` Dima Kogan
2015-10-30 14:20 ` Eli Zaretskii [this message]
2015-10-30 19:17 ` Dima Kogan
2015-10-30 20:38 ` Eli Zaretskii
2015-10-30 20:50 ` Dima Kogan
2015-11-09 2:55 ` Dima Kogan
2015-11-09 16:38 ` Eli Zaretskii
2019-11-17 6:34 ` Lars Ingebrigtsen
2019-11-17 15:38 ` Eli Zaretskii
2019-11-17 21:27 ` Dima Kogan
2019-11-18 8:13 ` Lars Ingebrigtsen
2015-09-29 10:05 ` K. Handa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83wpu4zbe6.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=21556@debbugs.gnu.org \
--cc=dima@secretsauce.net \
--cc=dmantipov@yandex.ru \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.