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

Previous Next

Full log

Message #86 received at 79131 <at> debbugs.gnu.org (full text, mbox):

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

> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Cc: Pip Cet <pipcet <at> protonmail.com>,  oscarfv <at> eclipso.eu,
>   casouri <at> gmail.com,  79131 <at> debbugs.gnu.org
> 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.

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.

Previous Next

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