unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
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
-- 





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