From: Robert Pluim <rpluim@gmail.com>
To: "Basil L. Contovounesios" <contovob@tcd.ie>
Cc: Lars Ingebrigtsen <larsi@gnus.org>, 42943@debbugs.gnu.org
Subject: bug#42943: 28.0.50; Emacsclient crashes in ftcrfont_glyph_extents
Date: Sat, 24 Oct 2020 13:24:42 +0200 [thread overview]
Message-ID: <m2a6wblvd1.fsf@gmail.com> (raw)
In-Reply-To: <877dtuta6z.fsf@tcd.ie>
>>>>> 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
--
next prev parent reply other threads:[~2020-10-24 11:24 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-20 0:47 bug#42943: 28.0.50; Emacsclient crashes in ftcrfont_glyph_extents Basil L. Contovounesios
2020-08-20 14:28 ` Eli Zaretskii
2020-08-21 14:05 ` Lars Ingebrigtsen
2020-10-22 12:41 ` Lars Ingebrigtsen
2020-10-22 22:11 ` Basil L. Contovounesios
2020-10-24 11:24 ` Robert Pluim [this message]
2020-10-24 11:46 ` Eli Zaretskii
2020-10-24 12:14 ` Robert Pluim
2020-10-24 13:10 ` Eli Zaretskii
2020-10-24 13:35 ` Robert Pluim
2020-10-24 13:27 ` Robert Pluim
2020-10-24 14:12 ` Eli Zaretskii
2020-10-24 14:48 ` Eli Zaretskii
2020-10-24 15:41 ` Robert Pluim
2020-10-24 15:52 ` Eli Zaretskii
2020-10-26 12:33 ` Robert Pluim
2020-10-26 16:16 ` Eli Zaretskii
2020-10-26 20:13 ` Basil L. Contovounesios
2020-10-24 15:34 ` Robert Pluim
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m2a6wblvd1.fsf@gmail.com \
--to=rpluim@gmail.com \
--cc=42943@debbugs.gnu.org \
--cc=contovob@tcd.ie \
--cc=larsi@gnus.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).