GNU bug report logs -
#72692
Emacs 31.05 (40eecd594ac) get SIGSEGV on Linux (Linux 6.6.45 Kde Wayland)
Previous Next
Reported by: Eval EXEC <execvy <at> gmail.com>
Date: Sun, 18 Aug 2024 08:31:01 UTC
Severity: normal
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
Full log
Message #32 received at 72692 <at> debbugs.gnu.org (full text, mbox):
> Cc: 72692 <at> 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 <at> 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 can confirm that we're sometimes leaving a frame's fontset field
> invalid by running this code:
If face2->ascii_face is equal to face->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;
And how did you see that a frame's fontset was left invalid here? A
frame doesn't have a fontset, AFAIK.
I don't object to using this code as a means of investigation, of
course, but I think we should have a clear idea of what the diagnostic
it emits means.
I also think it might be unsafe to call 'message' from this place,
because 'message' might trigger redisplay. It is better to call
message_dolog or add_to_log (and ask the user to look at *Messages*).
This bug report was last modified 257 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.