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

Previous Next

Full log

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

From: Pip Cet <pipcet <at> protonmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
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 16:08:39 +0000

"Eli Zaretskii" <eliz <at> gnu.org> writes:

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

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.

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

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

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

Pip

Previous Next

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