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

From: Eli Zaretskii <[email-masked]>
Date: Fri, 08 Aug 2025 09:18:48 +0300

> From: Gerd Möllmann <[email-masked]>
> Cc: Pip Cet <[email-masked]>,  [email-masked],
>   [email-masked],  [email-masked]
> Date: Fri, 08 Aug 2025 06:37:11 +0200
> 
> 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.  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?
> 
> While an algorithm is working on tree, the tree may temporarily become
> inconsisten. Quitting out of the algorithm where that is the case is a
> no-go.

Is that related to igc in some way?  The discussion was about igc
making this happen, or making it happen more frequently.  What you say
seem to be unrelated.