Re: MPS: a random backtrace while toying with gdb

[Pip Cet]

On Sunday, June 30th, 2024 at 10:34, Eli Zaretskii <eliz@gnu.org> wrote:
> > Date: Sun, 30 Jun 2024 10:16:42 +0000
> > From: Pip Cet pipcet@protonmail.com
> > Cc: gerd.moellmann@gmail.com, yantar92@posteo.net, emacs-devel@gnu.org, 
> > eller.helmut@gmail.com
> >
> > > > We could always "steal" the SIGSEGV handler and reinstall it with a 
> > > > sigmask (without modifying the MPS source). My guess is that's 
> > > > equivalent to what the macOS code does, essentially, by using a 
> > > > different class of signal that blocks POSIX signals...
> > >
> > > And this is less "ugly" (let alone more safe) than using sigblock?
> > > What am I missing?

And, yes, as far as I can tell my proposed solution is safer.

> > Mostly, I think, the race condition where the barrier is installed (by MPS) 
> > some time before dflt_scan is even called (and, symmetrically, we'd unblock 
> > it too early while the barrier is still in effect). IOW, sigblock wouldn't 
> > work.
>
>
> Then we should block signals earlier, e.g., in igc_alloc (and any
> other place which could cause our objects moved).

That would be a very expensive and error-prone way of achieving the same result 
as simply blocking the signals while handling SIGSEGV.

> > (I should point out that you've convinced me as far as SIGPROF goes. At 
> > least for the initial stage, it makes more sense to count hits in GC (which 
> > we do, with false positives, using the current scratch/igc code) than to 
> > delay signal processing until GC is over).
>
>
> SIGPROF is not the only one.

It's the only one where I am not convinced the right thing is to simply block 
it using sa_sigmask.

> We have other useful signals, and we
> need to think about a solution that will cover most if not all of
> them. I've listed the signals that came to mind a few messages ago.

Those would be handled just fine by blocking all but the known-to-be-safe 
SIGPROF while handling SIGSEGV.

> I still cannot believe MPS doesn't have a canonical solution for these
> cases.

I haven't been able to find one in the docs. It still seems a simple oversight 
in the MPS code to me that they don't simply block all signals while handling 
SIGSEGV, or provide an API to set the mask.

Pip