Re: MPS: a random backtrace while toying with gdb

[Pip Cet]

On Sunday, June 30th, 2024 at 10:09, Eli Zaretskii <eliz@gnu.org> wrote:

> 
> 
> > Date: Sun, 30 Jun 2024 09:59:17 +0000
> 
> > From: Pip Cet pipcet@protonmail.com
> > Cc: Ihor Radchenko yantar92@posteo.net, emacs-devel@gnu.org, Eli Zaretskii 
> > eliz@gnu.org, eller.helmut@gmail.com
> > 
> > On Saturday, June 29th, 2024 at 21:46, Gerd Möllmann 
> > gerd.moellmann@gmail.com wrote:
> > 
> > > Pip Cet pipcet@protonmail.com writes:
> > > 
> > > > On Saturday, June 29th, 2024 at 19:11, Ihor Radchenko 
> > > > yantar92@posteo.net wrote:
> > > > 
> > > > > I just got this while starting up Emacs on the latest scratch/igc 
> > > > > (with
> > > > > native-comp).
> > > > 
> > > > Looks like the same double-signal situation we saw with the profiler, 
> > > > only this time it's SIGCHLD interrupting an MPS scan.
> > > > 
> > > > Pip
> > > 
> > > Indeed
> > > 
> > > #10 0x0000555555827385 in PSEUDOVECTORP (a=XIL(0x7fffeb90875d), code=9) 
> > > at /home/yantar92/Git/emacs/src/lisp.h:1105
> > > #11 PROCESSP (a=XIL(0x7fffeb90875d)) at 
> > > /home/yantar92/Git/emacs/src/process.h:212
> > > #12 XPROCESS (a=XIL(0x7fffeb90875d)) at 
> > > /home/yantar92/Git/emacs/src/process.h:224
> > > #13 handle_child_signal (sig=sig@entry=17) at process.c:7660
> > > 
> > > Someone has an idea what to do with that? And maybe how to reproduce?
> > 
> > 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?

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.

(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).

Unfortunately, I can't reproduce the SIGCHLD problem with Helmut's code, which 
doesn't cause a single SIGSEGV here...

Pip