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

From: Pip Cet <[email-masked]>
Date: Thu, 07 Aug 2025 17:58:22 +0000

"Eli Zaretskii" <[email-masked]> writes:

>> From: Gerd Möllmann <[email-masked]>
>> Cc: Pip Cet <[email-masked]>,  [email-masked],
>>   [email-masked],  [email-masked]
>> Date: Sun, 03 Aug 2025 18:17:17 +0200
>>
>> Eli Zaretskii <[email-masked]> writes:
>>
>> >> Date: Sun, 03 Aug 2025 15:47:43 +0000
>> >> From: Pip Cet <[email-masked]>
>> >> Cc: Óscar Fuentes <[email-masked]>, Eli Zaretskii <[email-masked]>, Yuan Fu <[email-masked]>, [email-masked]
>> >>
>> >> Gerd Möllmann <[email-masked]> writes:
>> >>
>> >> > Pip Cet <[email-masked]> writes:
>> >> >
>> >> >> But I'll wait for others to weigh in; maybe my theory is obviously
>> >> >> incorrect.
>> >> >
>> >> > I think the memq thing is definitely a bug.
>> >>
>> >> 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).

So, if I'm right, I'm afraid we're going to have to go with _no_quit
versions for now, or abuse the unwind-protect machinery.

Using inhibit_quit would work for some quits, and possibly all of them,
but I'd have to read the code again to be sure.

Pip