[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#42943: 28.0.50; Emacsclient crashes in ftcrfont_glyph_extents
From: |
Robert Pluim |
Subject: |
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@gnu.org> said:
>> From: Robert Pluim <rpluim@gmail.com>
>> Cc: Lars Ingebrigtsen <larsi@gnus.org>, 42943@debbugs.gnu.org,
eliz@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@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
--
- bug#42943: 28.0.50; Emacsclient crashes in ftcrfont_glyph_extents, Lars Ingebrigtsen, 2020/10/22
- bug#42943: 28.0.50; Emacsclient crashes in ftcrfont_glyph_extents, Basil L. Contovounesios, 2020/10/22
- bug#42943: 28.0.50; Emacsclient crashes in ftcrfont_glyph_extents, Robert Pluim, 2020/10/24
- bug#42943: 28.0.50; Emacsclient crashes in ftcrfont_glyph_extents, Robert Pluim, 2020/10/24
- bug#42943: 28.0.50; Emacsclient crashes in ftcrfont_glyph_extents, Eli Zaretskii, 2020/10/24
- bug#42943: 28.0.50; Emacsclient crashes in ftcrfont_glyph_extents, Eli Zaretskii, 2020/10/24
- bug#42943: 28.0.50; Emacsclient crashes in ftcrfont_glyph_extents, Robert Pluim, 2020/10/24
- bug#42943: 28.0.50; Emacsclient crashes in ftcrfont_glyph_extents, Eli Zaretskii, 2020/10/24
- bug#42943: 28.0.50; Emacsclient crashes in ftcrfont_glyph_extents, Robert Pluim, 2020/10/26
- bug#42943: 28.0.50; Emacsclient crashes in ftcrfont_glyph_extents, Eli Zaretskii, 2020/10/26
- bug#42943: 28.0.50; Emacsclient crashes in ftcrfont_glyph_extents, Basil L. Contovounesios, 2020/10/26