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

From: Gerd Möllmann <[email-masked]>
Date: Fri, 08 Aug 2025 07:43:31 +0200

Gerd Möllmann <[email-masked]> writes:

> 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.

Maybe one could somewhere communicate, as a rule of thumb:

  When you write a C function that modifies a data structure, you must
  not call funcrtions that can signal an error or quit while the data
  structure is in an inconsistent state. Note that all C functions
  beginning