GNU bug report logs - #54661
29.0.50; Emacs SEGV in get_glyph_face_and_encoding

Previous Next

Package: emacs;

Reported by: James Ferguson <james <at> faff.org>

Date: Thu, 31 Mar 2022 21:53:02 UTC

Severity: normal

Tags: moreinfo

Found in version 29.0.50

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


Message #8 received at 54661 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: James Ferguson <james <at> faff.org>
Cc: 54661 <at> debbugs.gnu.org
Subject: Re: bug#54661: 29.0.50; Emacs SEGV in get_glyph_face_and_encoding
Date: Fri, 01 Apr 2022 10:40:35 +0300
> From: James Ferguson <james <at> faff.org>
> Date: Thu, 31 Mar 2022 17:19:03 -0400
> 
> My Emacs has SEGVing a few times (twice today), from a fairly recent
> build off `master`.  Sometimes it seems to have happened when doing
> autocompletion (using the `corfu` package), but it has definitely
> happened when idle from a user perspective.
> 
> I'm afraid I have a lot of packages active including lsp, and it's way
> too random and sporadic to be able to craft a cut-down config.
> 
> I will put the `bt full` output at the bottom of this email.  I have
> quite a few cores, but a quick check looks like they all have similar stack.
> That `face = 0x0` looks ... ominous(?).

Yes, that's the immediate reason for the segfault.  The question is:
how did that happen?  It usually happens because some code cleared the
frame's face cache between the time the window's glyph matrix was
created/updated, which holds the face for each glyph to be displayed,
and the time the window's display is actually drawn to the glass.  The
former part happens in redisplay_windows, called on line 16518 of
xdisp.c; the latter part happens inside update_frame, called on line
16598 of xdisp.c.  The way to debug this is to find which code empties
the face cache, and then figure out the control flow path which leads
to that code in your scenario.

Can you try figuring that out?  One way of doing so is to set up a
breakpoint in free_realized_faces, here:

      for (i = 0; i < c->used; ++i)  <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
	{
	  free_realized_face (f, c->faces_by_id[i]);
	  c->faces_by_id[i] = NULL;
	}

and enable this breakpoint only between the above two lines of
xdisp.c.  (You can do that via breakpoint commands of 2 more
breakpoints in xdisp.c, in the places I mentioned above: a breakpoint
on xdisp.c:16531 with commands that enable the breakpoint in
free_realized_face, and another on xdisp.c:16598 which disables that
breakpoint.)  Then in the breakpoint commands for the breakpoint in
free_realized_face, produce the C and Lisp backtrace (the latter with
xbacktrace command defined on src/.gdbinit), and post it here.  That
might tell us which code is doing this.

Thanks.




This bug report was last modified 3 years and 58 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.