Re: MPS: a random backtrace while toying with gdb

[Eli Zaretskii <eliz@gnu.org>]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: pipcet@protonmail.com,  yantar92@posteo.net,  emacs-devel@gnu.org,
>   eller.helmut@gmail.com
> Date: Sun, 30 Jun 2024 07:33:54 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> 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?
> >
> > Call sigblock at the beginning of dflt_scan (and friends) and
> > sigunblock before it returns?
> 
> Yuk.

Why "yuck"?  That's a valid solution, IMO, especially if there are no
better ones.  I'm talking about blocking only a small number of
signals: SIGCHLD, SIGPROF, SIGALRM, and maybe also SIGIO and SIGINT.
(We should also consider SIGUSR1 and SIGUSR2.)

> > Are there any guidance in the MPS docs for handling such signals in
> > these situations?  If not, can we ask them for guidance?  It is
> > unrealistic to expect any real-life program to do nothing in signal
> > handlers except setting flags.  And even flags could be subject to MPS
> > moving GC, at least in some cases.  So there must be some way of
> > dealing with that in a safe way.
> 
> It's Emacs' fault. MPS cannot reasonably be expected to assume that a
> client program uses MPS managed memory in a signal handler. My 2 cents.

That's unreasonable, IMNSHO.  Programs manage memory for various
purposes, and nothing in principle should prevent a program from
accessing MPS-managed memory from a signal handler.

Are you saying that a program that manages _all_ of its heap-allocated
memory via MPS cannot also handle signals in a safe way?

> >> And maybe how to reproduce?
> >
> > Run for enough time with subprocesses that start and terminate, I
> > guess?
> 
> Just remembered that I won't be able to reproduce this anyway an macOS,
> where barriers don't use signals.

AFAIU, this scenario is not necessarily related to barrier-related
signals.  SIGCHLD caused us to access MPS-managed memory, which
violated some assertion in MPS, because the arena lock was already
taken.