bug#42943: 28.0.50; Emacsclient crashes in ftcrfont_glyph_extents

[Robert Pluim <rpluim@gmail.com>]

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