Subject: bug#79131: 31.0.50; igc: nested signal, SIGSEGV

From: Eli Zaretskii <[email-masked]>
Date: Fri, 08 Aug 2025 15:39:33 +0300

> Date: Fri, 08 Aug 2025 12:10:14 +0000
> From: Pip Cet <[email-masked]>
> Cc: [email-masked], [email-masked], [email-masked], [email-masked]
> 
> "Eli Zaretskii" <[email-masked]> writes:
> 
> >> Date: Thu, 07 Aug 2025 17:58:22 +0000
> >> From: Pip Cet <[email-masked]>
> >> Cc: Gerd Möllmann <[email-masked]>, [email-masked], [email-masked], [email-masked]
> >>
> >> "Eli Zaretskii" <[email-masked]> writes:
> >>
> >> >> >> Unfortunately, while Fmemq and Fassq are easy to fix, Fget can also quit
> >> >> >> (if overriding-plist-environment is in use), and that's used in a few
> >> >> >> places here.  Do we need get_no_quit?
> >> >> >
> >> >> > Maybe we should inhibit_igc instead (if we don't already)?  Otherwise,
> >> >>
> >> >> You mean inhibit-quit?
> >> >
> >> > No, I mean prevent MPS from interrupting a given short sequence of
> >> > code with GC.
> >>
> >> I fail to see how that would work in this case, sorry. What makes this
> >> bug more likely on MPS (it exists on both branches, if it is as I
> >> described) is the existence of memory barriers, not the start of a GC
> >> cycle (which we could, in theory, stop, though we really shouldn't).
> >
> > You were talking about Fmemq and Fassq vs memq_no_quit and
> > assq_no_quit, and that the former could leave the intervals in
> > inconsistent state.
> 
> That is correct.
> 
> > What do memory barriers have to do with that?
> 
> As I said, I think they make this bug scenario more likely. When MPS
> hits a memory barrier, it doesn't just work to clear the memory barrier,
> but (by default) it performs some extra work to make progress on the GC.
> 
> It is these interruptions I was talking about. We can't prevent them,
> because they're what makes MPS work. We can reduce the pause time, which
> reduces or removes the extra work done by MPS in this situation, but I
> don't think we want to do that just to reduce the likelihood of running
> into known and fixable bugs.
> 
> > The no-quit versions don't disable memory barriers, do they?
> 
> No, they just prevent quitting out of the interval management functions
> while the state is inconsistent (in particular, after the buffer text
> size changed and before the interval tree size was updated to reflect
> that).
> 
> So I'm still failing to see what "inhibit_igc" would even do, and I
> don't think it would help in this case.

As usual, these discussions are quickly becoming theoretical and
disconnected from reality, and we are talking past each other.  To
make this useful, please point to specific places where the
problematic functions (Fmemq etc.) are called while the intervals
could be in inconsistent state, and let's take it from there.