From: Robert Pluim <rpluim@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: contovob@tcd.ie, larsi@gnus.org, 42943@debbugs.gnu.org
Subject: bug#42943: 28.0.50; Emacsclient crashes in ftcrfont_glyph_extents
Date: Sat, 24 Oct 2020 14:14:53 +0200 [thread overview]
Message-ID: <m25z6zlt1e.fsf@gmail.com> (raw)
In-Reply-To: <83lffvhmne.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 24 Oct 2020 14:46:29 +0300")
>>>>> 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
--
next prev parent reply other threads:[~2020-10-24 12:14 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
2020-10-24 11:46 ` Eli Zaretskii
2020-10-24 12:14 ` Robert Pluim [this message]
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=m25z6zlt1e.fsf@gmail.com \
--to=rpluim@gmail.com \
--cc=42943@debbugs.gnu.org \
--cc=contovob@tcd.ie \
--cc=eliz@gnu.org \
--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).