GNU bug report logs - #79131
31.0.50; igc: nested signal, SIGSEGV

Previous Next

Full log

View this message in rfc822 format

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: oscarfv <at> eclipso.eu, Pip Cet <pipcet <at> protonmail.com>, 79131 <at> debbugs.gnu.org, casouri <at> gmail.com
Subject: bug#79131: 31.0.50; igc: nested signal, SIGSEGV
Date: Fri, 08 Aug 2025 06:37:11 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Date: Thu, 07 Aug 2025 17:58:22 +0000
>> From: Pip Cet <pipcet <at> protonmail.com>
>> Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>, oscarfv <at> eclipso.eu,
>> casouri <at> gmail.com, 79131 <at> debbugs.gnu.org
>> 
>> "Eli Zaretskii" <eliz <at> gnu.org> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.