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

Previous Next

Full log

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

From: Robert Pluim <rpluim <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
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:14:53 +0200

>>>>> On Sat, 24 Oct 2020 14:46:29 +0300, Eli Zaretskii <eliz <at> gnu.org> said:

    >> 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.

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

Yes, weʼre using the face thatʼs cached in the glyph_string:

Thread 1 "emacs" received signal SIGSEGV, Segmentation fault.
ftcrfont_glyph_extents (font=0x555556930478, glyph=1036,
    metrics=metrics <at> entry=0x0) at ftcrfont.c:81
81        if (METRICS_STATUS (cache) == METRICS_INVALID)
(gdb) up
#1  0x00005555558453a1 in ftcrfont_draw (s=0x7fffffffb440,
    from=<optimized out>, to=<optimized out>, x=17, y=<optimized out>,
    with_background=<optimized out>) at ftcrfont.c:520
520           x += (s->padding_p ? 1 : ftcrfont_glyph_extents (s->font,
(gdb) l 500
495       struct face *face = s->face;
496       struct font_info *ftcrfont_info = (struct font_info *) s->font;
497       cairo_t *cr;
498       cairo_glyph_t *glyphs;
499       int len = to - from;
500       int i;
501
502       block_input ();
503
504       cr = x_begin_cr_clip (f, s->gc);
(gdb) p s->face
$1 = (struct face *) 0x555556113290
(gdb) p s->face->font
$2 = (struct font *) 0x555556930478
(gdb) p s->font
$3 = (struct font *) 0x555556930478

(this is from a separate run from the valgrind one)

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

font_clear_cache closes all the fonts and sets the frame's font cache
to Qnil, I donʼt see it doing anything with faces.

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

Itʼs just emacsclient redisplaying *scratch*, I think. Are you saying redisplay
should not be called here?

Robert
-- 

Previous Next

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