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

Previous Next

Full log

Message #44 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 18:38:14 +0300

> Date: Sun, 18 Aug 2024 14:59:51 +0000
> From: Pip Cet <pipcet <at> protonmail.com>
> Cc: execvy <at> gmail.com, 72692 <at> debbugs.gnu.org
> 
> I don't understand yet what underlying assumption is violated, and what
> precisely happened.
> 
> But I have just reproduced the crash, I think. It does need this patch,
> which means we will actually crash when accessing a formerly-valid
> fontset, rather than accessing random and inappropriate data, so I think
> we need to first establish that this patch doesn't break things and
> cause a different crash.

I don't understand: is this patch needed to trigger a crash, or are
you saying we need it to fix crashes?

next_fontset_id is used to assign an ID to the next fontset we create,
AFAIK.

> > 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?

> >> 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?

Previous Next

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