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

From: Eli Zaretskii <[email-masked]>
Date: Thu, 07 Aug 2025 21:48:24 +0300

> 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.  What do memory barriers have to do with that?
The no-quit versions don't disable memory barriers, do they?

Or what am I missing?