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

Previous Next

Full log

Message #59 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 21:38:36 +0300

> Date: Sun, 18 Aug 2024 17:56:12 +0000
> From: Pip Cet <pipcet <at> protonmail.com>
> Cc: execvy <at> gmail.com, 72692 <at> debbugs.gnu.org
> 
> "Pip Cet" <pipcet <at> protonmail.com> writes:
> 
> > "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.
> 
> And I understand why it's so rare now: the non-ASCII face contains a
> dangling pointer to the (freed!) old ASCII face, and we verify in
> 'face_for_font' that the pointer matches the new ASCII face, which it
> can do only if the new ASCII face happens to be allocated at the same
> address the old one had.
> 
> But, it happens, and we need to fix it somehow.  The easiest fix would
> be to use a refcount in 'struct face' and do the actual freeing (of
> fontset and struct face) only when no other 'struct face' refers to our
> face through ->ascii_face.
> 
> Or is there a simpler solution?

I don't understand what you are saying, because there isn't enough
details.  How does the "dangling pointer to the freed old ASCII face"
come into existence, by which code and in what situation?  What do you
mean by "the new ASCII face happens to be allocated at the same
address the old one had" -- is that the address of 'struct face', and
if so, are you saying that malloc returns to us the same address in
most cases? how's that possible?

Please, PLEASE describe the issue with enough details and pointers to
the code, and preferably back that up with data from a debugging
session.  That's the only way to conduct this kind of discussion while
making sure all of the participants are on the same page, and can help
each other with ideas and their respective knowledge of Emacs
internals.

Here's one data point: this kind of problem has never, NEVER happened
to me, although I display non-ASCII text in my Emacs sessions quite a
lot.  So if what you describe is so trivially easy to trigger, how
come it didn't happen to me, in all the years I'm using this code?

There has to be more to this than meets the eye, and we can only
figure this out if you provide all the missing details.

Previous Next

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