bug#42943: 28.0.50; Emacsclient crashes in ftcrfont_glyph_extents

[Robert Pluim]

>>>>> On Thu, 22 Oct 2020 23:11:30 +0100, "Basil L. Contovounesios" 
>>>>> <contovob@tcd.ie> said:

    Basil> Sadly, it doesn't seem to have - I still get a segfault, at least in 
my
    Basil> optimised build of master.  Hopefully I'll find some time over the
    Basil> weekend to look into it.

I can reproduce this with a GTK3 + cairo build. Your recipe is very
helpful, in fact just doing 'C-\ arabic RET' is enough to cause the
second emacsclient invocation to crash.

Running emacs under valgrind shows what's going on, but I donʼt know
how to fix it:

==9766== Invalid read of size 2
==9766==    at 0x3F8FED: ftcrfont_glyph_extents (ftcrfont.c:81)
==9766==    by 0x3F93A0: ftcrfont_draw (ftcrfont.c:522)
==9766==    by 0x25C67F: x_draw_composite_glyph_string_foreground (xterm.c:1969)
==9766==    by 0x25F9A4: x_draw_glyph_string (xterm.c:3780)
==9766==    by 0x1BFC4D: draw_glyphs (xdisp.c:28915)
==9766==    by 0x1C65EA: gui_write_glyphs (xdisp.c:30933)
==9766==    by 0x15227D: update_text_area (dispnew.c:3849)
==9766==    by 0x152C38: update_window_line (dispnew.c:4092)
==9766==    by 0x151858: update_window (dispnew.c:3573)
==9766==    by 0x151015: update_window_tree (dispnew.c:3344)
==9766==    by 0x150C48: update_frame (dispnew.c:3226)
==9766==    by 0x19766E: redisplay_internal (xdisp.c:16023)
==9766==  Address 0xf36a92e is 126 bytes inside a block of size 1,280 free'd
==9766==    at 0x48369AB: free (vg_replace_malloc.c:530)
==9766==    by 0x327438: xfree (alloc.c:820)
==9766==    by 0x3F9EF4: ftcrfont_close (ftcrfont.c:307)
==9766==    by 0x3F9EF4: ftcrfont_close (ftcrfont.c:282)
==9766==    by 0x37B285: font_clear_cache (font.c:2648)
==9766==    by 0x37B096: font_finish_cache (font.c:2593)
==9766==    by 0x37E258: font_update_drivers (font.c:3588)
==9766==    by 0x15F56E: delete_frame (frame.c:2093)
==9766==    by 0x15FD21: Fdelete_frame (frame.c:2325)
==9766==    by 0x35F1FD: funcall_subr (eval.c:2884)
==9766==    by 0x35EDE9: Ffuncall (eval.c:2809)
==9766==    by 0x356002: Ffuncall_interactively (callint.c:253)
==9766==    by 0x35F0FC: funcall_subr (eval.c:2862)
==9766==  Block was alloc'd at
==9766==    at 0x483577F: malloc (vg_replace_malloc.c:299)
==9766==    by 0x327BEB: lmalloc (alloc.c:1359)
==9766==    by 0x3272FA: xmalloc (alloc.c:761)
==9766==    by 0x3F9093: ftcrfont_glyph_extents (ftcrfont.c:73)
==9766==    by 0x3F94B2: ftcrfont_text_extents (ftcrfont.c:371)
==9766==    by 0x3803DA: font_fill_lglyph_metrics (font.c:4430)
==9766==    by 0x3E1736: fill_gstring_body (composite.c:843)
==9766==    by 0x3E42C4: Fcomposition_get_gstring (composite.c:1792)
==9766==    by 0x3E1BC3: autocmp_chars (composite.c:912)
==9766==    by 0x3E2BCE: composition_reseat_it (composite.c:1269)
==9766==    by 0x1858B9: next_element_from_string (xdisp.c:8578)
==9766==    by 0x1854C6: next_element_from_string (xdisp.c:8504)


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.

Robert
--