Subject: bug#72692: Emacs 31.05 (40eecd594ac) get SIGSEGV on Linux (Linux 6.6.45 Kde Wayland)

From: Pip Cet <[email-masked]>
Date: Sun, 18 Aug 2024 16:08:39 +0000

"Eli Zaretskii" <[email-masked]> writes:

>> Date: Sun, 18 Aug 2024 14:59:51 +0000
>> From: Pip Cet <[email-masked]>
>> Cc: [email-masked], [email-masked]
>>
>> 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