GNU bug report logs - #42943
28.0.50; Emacsclient crashes in ftcrfont_glyph_extents

Previous Next

Full log

Message #23 received at 42943 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: contovob <at> tcd.ie, larsi <at> gnus.org, 42943 <at> debbugs.gnu.org
Subject: Re: bug#42943: 28.0.50; Emacsclient crashes in ftcrfont_glyph_extents
Date: Sat, 24 Oct 2020 14:46:29 +0300

> From: Robert Pluim <rpluim <at> gmail.com>
> Cc: Lars Ingebrigtsen <larsi <at> gnus.org>,  42943 <at> debbugs.gnu.org, eliz <at> gnu.org
> Date: Sat, 24 Oct 2020 13:24:42 +0200
> 
> The call to ftcrfont_glyph_extents is from here:
> 
>     static int
>     ftcrfont_draw (struct glyph_string *s,
>                    int from, int to, int x, int y, bool with_background)
>     {
>       struct frame *f = s->f;
>       struct face *face = s->face;
>       struct font_info *ftcrfont_info = (struct font_info *) s->font;
> 
> So this means that the struct glyph_string here still refers to the
> font from the previous frame, which has been closed. Iʼm not sure how
> to get it to refer to the right font on the new frame.

I'm guessing that we close the font, but there's still a face that
references that font, and we try using that face for display.  Can you
see if that is the case?  The 'face' member of 'struct glyph_string'
should point to the face, and face->font should point to the font.

We call font_clear_cache when a frame is deleted, so it's unclear to
me how come the font is still remembered somewhere.

And I lack some background here: what is/are the character(s) we try
displaying here, and how that display is triggered by creating a new
frame due to the second emacsclient invocation?

Previous Next

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