Re: MPS signals and Emacs (was: STatus of MPS branch)

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: emacs-devel <emacs-devel@gnu.org>
> Date: Mon, 22 Apr 2024 07:28:40 +0200
> 
> Helmut Eller <eller.helmut@gmail.com> writes:
> 
> > I changed some things and now I can no longer reproduce the exact same
> > problem.  But it looked to me like a perfectly normal string with
> > intervals=0x0.  Strangely, accessing the intervals field from GDB didn't
> > cause any SIGSEGV.
> >
> > However, after setting breakpoints in handle_sigsegv and sigHandle (from
> > MPS) I discovered that sigHandle wasn't called.  So my hypothesis is
> > that the signal handler isn't initialized properly.  In particular, it
> > seems problematic that ProtSetup (from MPS) is called before
> > init_signals.
> >
> > Then I moved the call to init_signals in emacs.c up before the call to
> > init_igc and voilà: the build completed.  With an apparently working
> > (tty-only) Emacs.
> 
> Oh, I have an idea! Hopefully I can explain it. Let me try...
> 
> MPS is a copying GC, and it uses read-barriers for object forwarding.
> 
> Let's say O is an object managed by MPS, and it decides during GC that O
> shall be moved in memory to the new location N. This is done by copying
> O to N, storing at O the information that it has moved to N, and putting
> a read-barrier on O.
> 
> The last step means that any access to O by the client (Emacs) leads to
> MPS being involved, which updates the reference to O to a reference to
> N.
> 
> Plus...
> 
> MacOS has a kernel that is, let's not get into details, a conglomerate
> of Mach and FreeBSD kernel. This means MPS can use Mach mechanisms for
> implementing read/write barriers, and I know it does because I landed in
> that code in LLDB at some point.
> 
> Linux is not Mach, so MPS must use VM protection and signals.
> 
> And finally, the idea now would be that MPS's signal handling (probably
> SIGSEGV and SIGBUS) and Emacs' signal handling interfere with one
> another.
> 
> For example, MPS has done its thing and read-protected O from above.
> Emacs accesses O, a SEGV is signaled, Emacs gets the signal and thinks
> it's bit the dust. And so on.
> 
> Or, IOW, we need some Emacs signal handling support personal.

Paul, can you please help by suggesting how to handle this situation?