Re: MPS: a random backtrace while toying with gdb

[Eli Zaretskii]

> 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 08:43:02 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > 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.)
> 
> I find that really ugly. Of course, should there be no other solution on
> some platforms, we can try that. It's not needed for macOS, for example.

We should only block signals where that is necessary, of course.

> >> > 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.
> 
> I disagree.
> 
> > Are you saying that a program that manages _all_ of its heap-allocated
> > memory via MPS cannot also handle signals in a safe way?
> 
> The program can do both, but only if the signal handler behaves. There
> is not much a signal handler is allowed to do. Portably it can do almost
> nothing. But even non-portably, it's never safe to call non-reentrant
> code. On Linux, there is a list of async-signal-safe functions one can
> call in a signal handler, others cannot be used.

Which unsafe function did we call in this case, though?  AFAICT, we
simply accessed memory that happens to be behind the barrier:

  #9  0x00007ffff3048050 in <signal handler called> () at /lib64/libc.so.6
  #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

Line 7660 of process.c is this:

      struct Lisp_Process *p = XPROCESS (proc);

What "crime" did we commit here?

> I don't expect MPS to be async-signal-safe. I find that unreasonble.
> Why would it be? Emacs's isn't either. Almost nothing is.

See above: I'm not sure this is about async-signal-safety.

> >> 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.
> 
> I would have to see an example where no barrier is involved. It is in
> this case. MPS is doing work, therefore holds the lock, receives SIGxy
> which it let's the client handle. The client hits a barrier, which
> invokes MPS's signal handler, which tries to acquire the lock which is
> already taken.

Wouldn't the equivalent mechanism used on macOS also want to acquire
the arena lock in this case?  If not, what will it do?