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

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Pip Cet <pipcet <at> protonmail.com>
Cc: gerd.moellmann <at> gmail.com, oscarfv <at> eclipso.eu, casouri <at> gmail.com,
 79131 <at> debbugs.gnu.org
Subject: Re: bug#79131: 31.0.50; igc: nested signal, SIGSEGV
Date: Thu, 07 Aug 2025 21:48:24 +0300

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

Previous Next

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