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

Previous Next

Full log

Message #50 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: Sun, 18 Aug 2024 20:55:09 +0300

> Date: Sun, 18 Aug 2024 16:08:39 +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:
> 
> > I don't understand: is this patch needed to trigger a crash, or are
> > you saying we need it to fix crashes?
> 
> It helps trigger the crash, which might take a long time without the
> patch.
> 
> > next_fontset_id is used to assign an ID to the next fontset we create,
> > AFAIK.
> 
> Indeed, and if we never reset it to a low value, we won't reuse slots in
> Vfontset_table.  So the entries, rather than containing a different and
> incorrect fontset for our font, will remain zeroed.

How can incorrect fontset in Vfontset_table cause a segfault of the
kind the OP reported?

> >> > A "non-ASCII face" is basically
> >> > the same face as its "ASCII face" counterpart, it just uses a
> >> > different font.  An example would be some well-known face, like 'bold'
> >> > or 'variable-pitch' or 'region' -- when we need to display a non-ASCII
> >> > character in this face, and the "ASCII face"s font doesn't support the
> >> > character, we internally create a new face that uses the same fontset
> >> > as the "ASCII face".  This new face basically shadows the "ASCII face"
> >> > (and is never exposed to Lisp) and is for every practical purpose an
> >> > integral part of that "ASCII face" -- they always go together.
> >>
> >> Except they're not freed together?
> >
> > How do you see that?
> 
> printf debugging.

Which shows what exactly?

> >> >> I meant "face", sorry!  The non-ASCII face remains in the font cache,
> >> >> and its fontset is set to the newly freed fontset's ID, which is likely
> >> >> soon to be reused; only if it isn't, we see a crash.
> >> >
> >> > That shouldn't happen, AFAIU, except for very brief periods of time,
> >> > since we free the cached faces one by one, see free_realized_faces.
> >>
> >> Again, not what I'm seeing, because 'free_realized_faces' isn't where the
> >> font is actually removed from the cache; it's 'free_realized_face'.
> >
> > Yes, but free_realized_faces calls free_realized_face, no?
> 
> Yes, it does, but in my case, 'free_realized_face' is called by
> 'realize_face', and 'free_realized_faces' isn't.

Which face was freed, the ASCII face or not?

> I'll continue debugging this, but if there are any questions or further
> helpful information, that would be much appreciated.

I don't yet understand well what you are seeing because there isn't
enough detailed information.

Previous Next

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