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

From: Gerd Möllmann <[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.