From: Pip Cet via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: execvy@gmail.com, 72692@debbugs.gnu.org
Subject: bug#72692: Emacs 31.05 (40eecd594ac) get SIGSEGV on Linux (Linux 6.6.45 Kde Wayland)
Date: Sun, 18 Aug 2024 14:59:51 +0000 [thread overview]
Message-ID: <87y14tg9ln.fsf@protonmail.com> (raw)
In-Reply-To: <86cym5zzq9.fsf@gnu.org>
"Eli Zaretskii" <eliz@gnu.org> writes:
>> Date: Sun, 18 Aug 2024 13:44:41 +0000
>> From: Pip Cet <pipcet@protonmail.com>
>> Cc: execvy@gmail.com, 72692@debbugs.gnu.org
>>
>> "Eli Zaretskii" <eliz@gnu.org> writes:
>>
>> >> Cc: 72692@debbugs.gnu.org
>> >> Date: Sun, 18 Aug 2024 12:43:06 +0000
>> >> From: Pip Cet via "Bug reports for GNU Emacs,
>> >> the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>> >>
>> >> Thanks. That has a different fontset, so it looks like a fontset was
>> >> prematurely freed while still being referred to by a face. I think the
>> >> assumption made in xfaces.c, that it's always safe to free a fontset if
>> >> we're freeing the realized ASCII face, is incorrect.
>> >
>> > Why do you think that? free_realized_face frees a face, so what other
>> > face can still use the same fontset, if it's a so-called "ASCII face"?
>>
>> I was under the impression two faces could share the same fontset. That
>> certainly is what my debugging sessions so far indicate. Maybe that's
>> the bug?
>
> We are talking about a fontset identified by face->fontset. AFAIU,
> face->fontset is only non-negative for so-called "ASCII faces".
Not what I'm seeing. base_face->fontset is copied into the new face by
realize_non_ascii_face.
>> > then I see no
>> > reason not to free the fontset because of that other face. The
>> > comment in dispextern.h says:
>> >
>> > /* Fontset ID if for this face's fontset. Non-ASCII faces derived
>> > from the same ASCII face have the same fontset. */
>> > int fontset;
>>
>> So, indeed, the fontset id is shared between the ASCII face and the
>> non-ASCII face. If we free the fontset because the ASCII face is
>> unrealized, but the non-ASCII face is not, we hit the bug...
>
> But AFAIK a non-ASCII face is always released together with its ASCII
> face,
Also not what I'm seeing. When 'realize_basic_faces' is called, we call
'realize_face', which destroys the fontset, even though it's still in
use by the non-ASCII face.
> so how can this be a problem?
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.
diff --git a/src/fontset.c b/src/fontset.c
index 16d14669c89..41d845c9bc5 100644
--- a/src/fontset.c
+++ b/src/fontset.c
@@ -921,8 +921,6 @@ free_face_fontset (struct frame *f, struct face *face)
eassert (! BASE_FONTSET_P (fontset));
eassert (f == XFRAME (FONTSET_FRAME (fontset)));
ASET (Vfontset_table, face->fontset, Qnil);
- if (face->fontset < next_fontset_id)
- next_fontset_id = face->fontset;
if (! NILP (FONTSET_DEFAULT (fontset)))
{
int id = XFIXNUM (FONTSET_ID (FONTSET_DEFAULT (fontset)));
@@ -931,8 +929,6 @@ free_face_fontset (struct frame *f, struct face *face)
eassert (!NILP (fontset) && ! BASE_FONTSET_P (fontset));
eassert (f == XFRAME (FONTSET_FRAME (fontset)));
ASET (Vfontset_table, id, Qnil);
- if (id < next_fontset_id)
- next_fontset_id = face->fontset;
}
face->fontset = -1;
}
and this Emacs Lisp script:
(display-time-mode t)
(let ((i 0))
(while t
(dolist (f (frame-list))
(push (concat (make-string 1 (floor (random 132000)))
(make-string 1 (floor (random 132000)))
(make-string 1 (floor (random 132000)))
(make-string 1 (floor (random 132000))))
mode-line-format)
(set-frame-parameter f 'alpha-background 1.0)
(sit-for 0)
(cl-incf i)
(message "%S" i)
(set-frame-parameter f 'alpha-background 0.9)
(sit-for 0)
(garbage-collect))))
(Not minimized yet).
> 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?
>> > And how did you see that a frame's fontset was left invalid here? A
>> > frame doesn't have a fontset, AFAIK.
>>
>> 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'.
I'd like to understand what is happening a bit better before submitting
a proposed fix.
Pip
next prev parent reply other threads:[~2024-08-18 14:59 UTC|newest]
Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-18 8:29 bug#72692: Emacs 31.05 (40eecd594ac) get SIGSEGV on Linux (Linux 6.6.45 Kde Wayland) Eval EXEC
2024-08-18 8:58 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-08-18 9:08 ` Eval EXEC
2024-08-18 9:23 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-08-18 9:24 ` execvy
2024-08-18 9:34 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-08-18 9:36 ` execvy
2024-08-18 12:43 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-08-18 12:53 ` execvy
2024-08-18 13:35 ` Eli Zaretskii
2024-08-18 13:44 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-08-18 14:12 ` Eli Zaretskii
2024-08-18 14:59 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
2024-08-18 15:38 ` Eli Zaretskii
2024-08-18 16:08 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-08-18 17:55 ` Eli Zaretskii
2024-08-18 18:11 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-08-18 18:52 ` Eli Zaretskii
2024-08-19 6:17 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-08-18 17:56 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-08-18 18:38 ` Eli Zaretskii
2024-08-19 6:28 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-08-19 11:30 ` Eli Zaretskii
2024-08-19 13:32 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-08-19 14:35 ` Eli Zaretskii
2024-08-19 15:03 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-08-19 15:54 ` Eli Zaretskii
2024-08-19 16:34 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-08-19 16:49 ` Eli Zaretskii
2024-08-24 9:09 ` Eli Zaretskii
2024-08-24 10:04 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-08-24 10:13 ` Eli Zaretskii
2024-08-25 17:58 ` Juri Linkov
2024-08-25 18:49 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-08-27 16:31 ` Juri Linkov
2024-08-28 11:50 ` Eli Zaretskii
2024-08-28 16:21 ` Juri Linkov
2024-08-28 17:53 ` Eli Zaretskii
2024-08-28 18:35 ` Juri Linkov
2024-08-28 18:57 ` Eli Zaretskii
2024-08-28 19:02 ` Juri Linkov
2024-08-29 4:36 ` Eli Zaretskii
2024-08-29 10:06 ` Eli Zaretskii
2024-08-29 12:06 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-08-29 12:26 ` Eli Zaretskii
2024-09-07 7:52 ` Eli Zaretskii
2024-09-08 0:42 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-08-28 17:56 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-08-25 18:57 ` Eli Zaretskii
2024-08-26 5:52 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-08-26 12:39 ` Eli Zaretskii
2024-08-26 19:04 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-08-26 19:20 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-08-27 11:47 ` Eli Zaretskii
2024-08-27 19:26 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-08-28 11:48 ` Eli Zaretskii
2024-08-28 11:58 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-08-27 11:44 ` Eli Zaretskii
2024-08-27 19:23 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-08-28 11:41 ` Eli Zaretskii
2024-08-28 12:07 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-08-28 12:51 ` Eli Zaretskii
2024-08-18 19:24 ` Eli Zaretskii
2024-08-19 6:07 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-08-19 14:17 ` Eli Zaretskii
2024-08-19 14:44 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87y14tg9ln.fsf@protonmail.com \
--to=bug-gnu-emacs@gnu.org \
--cc=72692@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=execvy@gmail.com \
--cc=pipcet@protonmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.