GNU bug report logs - #72692
Emacs 31.05 (40eecd594ac) get SIGSEGV on Linux (Linux 6.6.45 Kde Wayland)

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Pip Cet <pipcet <at> protonmail.com>
Cc: execvy <at> gmail.com, 72692 <at> debbugs.gnu.org
Subject: Re: bug#72692: Emacs 31.05 (40eecd594ac) get SIGSEGV on Linux (Linux
 6.6.45 Kde Wayland)
Date: Mon, 19 Aug 2024 14:30:09 +0300

> Date: Mon, 19 Aug 2024 06:28:32 +0000
> From: Pip Cet <pipcet <at> protonmail.com>
> Cc: execvy <at> gmail.com, 72692 <at> debbugs.gnu.org
> 
> "Eli Zaretskii" <eliz <at> gnu.org> writes:
> 
> > Here's one data point: this kind of problem has never, NEVER happened
> > to me, although I display non-ASCII text in my Emacs sessions quite a
> > lot.  So if what you describe is so trivially easy to trigger, how
> > come it didn't happen to me, in all the years I'm using this code?
> 
> It isn't trivially easy to trigger at all! To trigger it reliably, you
> need to:
> 
> * apply the patch so we don't reuse fontset table entries, which
>   otherwise hides the bug

But the OP didn't use that patch.  And your description sounded like
the problem could happen quite frequently even without that patch.

> * modify the mode line to use two new non-ASCII faces, at once, by
>   inserting two characters provided by different fonts

Why does it have to be the mode line? why not buffer text?  Mixing
different fonts (i.e. non-ASCII faces) in the same buffer is quite
common in Emacs; e.g., try "C-h h".

Also, why do we need more than one non-ASCII face to trigger the
problem?

> * modify the right frame parameter (such as alpha-background) so that
>   the basic faces are re-realized ('free_realized_face' is called for
>   them), but 'free_realized_faces' is not.

Basic faces are routinely freed and re-realized whenever we start the
display iteration, see init_iterator.  AFAIR, all you need to do for
that is to customize some face -- doing so sets the face_change flag,
and init_iterator will then normally free all the faces and realize
them again.

> * be unlucky in your choice of malloc implementation

"Unlucky" in what sense?

And if all the users of GNU/Linux (i.e. glibc) are thus "unlucky",
this still leaves us with many potential victims.

> In particular, I'd like to understand why we need to use two non-ASCII
> faces at once.

Maybe I don't understand the question, but we need a new non-ASCII
face each time we find a character for which existing non-ASCII faces
don't have a glyph.

Previous Next

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