[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 15:35:43 +0200 |
>>>>> On Sat, 24 Oct 2020 16:10:31 +0300, Eli Zaretskii <eliz@gnu.org> said:
>> From: Robert Pluim <rpluim@gmail.com>
>> Cc: contovob@tcd.ie, larsi@gnus.org, 42943@debbugs.gnu.org
>> Date: Sat, 24 Oct 2020 14:14:53 +0200
>>
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:
Eli> But glyph_strings are not kept between redisplay cycles, AFAIR, they
Eli> are recreated anew each time we need to redisplay something. This
Eli> happens in the write_glyphs method that is called from update_window
Eli> and update_frame, which eventually calls gui_write_glyphs, which calls
Eli> draw_glyphs, which creates the glyph_strings in BUILD_GLYPH_STRINGS.
Eli> So it's unclear to me how can a face be cached in a glyph_string.
Youʼre right, itʼs not cached in the glyph_string, itʼs cached in the
composition_gstring thatʼs used to create the glyph_string (see my
other message).
Eli> And how do you see from the above that it's a pointer to the same
Eli> 'struct font' that was used by the now-deleted first client frame?
thatʼs what the valgrind trace earlier said.
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> Faces are cached in the frame's face cache, see xfaces.c. When a
Eli> frame is deleted, its face cache is freed, so its faces should also go
Eli> away. A new frame starts with an empty face cache, and then faces are
Eli> added to that cache as they are "realized", starting from the "basic
Eli> faces" that are always needed, see realize_basic_faces. For a
Eli> non-ASCII character, we produce a new face based on the default face,
Eli> the first time we need to display a character that needs a font we
Eli> don't already have; then that face is also added to the frame's face
Eli> cache.
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.
Eli> And *scratch* has an Arabic character? How did that happen? I thought
Eli> the recipe was only to turn on the Arabic input method. Is the
Eli> offending character the IM indicator on the mode-line, per chance?
Yes, I suspect so, since there are no Arabic characters in *scratch*
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
- bug#42943: 28.0.50; Emacsclient crashes in ftcrfont_glyph_extents, Robert Pluim, 2020/10/24