Re: MPS: a random backtrace while toying with gdb

[Eli Zaretskii <eliz@gnu.org>]

> Date: Tue, 02 Jul 2024 07:55:26 +0000
> From: Pip Cet <pipcet@protonmail.com>
> Cc: eller.helmut@gmail.com, gerd.moellmann@gmail.com, yantar92@posteo.net, emacs-devel@gnu.org
> 
> > Which is why I suggested to block the signals before calling MPS and
> > unblock them immediately when we return from an MPS call. All of
> > these calls are in igc.c, so the job of adding these blocks, while
> > mundane and boring, is not impossible.
> 
> And it adds two syscalls to what should be a very fast operation. I'm not convinced it's necessary.

We should time these syscalls if we are afraid they could slow us
down.

> > That's not the problem, AFAIU. The problem is that a signal handler
> > which accesses Lisp data or the state of the Lisp machine could
> > trigger an MPS call, which will try taking the arena lock, and that
> > cannot be nested, by MPS design. And our handlers do access the Lisp
> > machine, albeit cautiously and as little as necessary. So when the
> > signal happens in the middle of an MPS call which already took the
> > arena lock, we cannot safely access our data.
> 
> I've tried quite hard to make this happen, but I didn't manage it. It seems that whenever MPS puts up a protection barrier for existing allocated memory, the arena lock has already been released. As signal handlers cannot allocate memory directly, there's no deadlock, either.
> 
> I don't understand MPS as well as you apparently do, so could you help me and tell where to put a kill(getpid(), SIGWHATEVER) with an appropriate signal handler which will cause a crash (without, in the signal handler, allocating memory)?

I thought using the profiler would trigger these easily enough?  I
think someone (Helmut?) posted a simple recipe for reproducing that
some time ago?

Also, there was a recipe with SIGCHLD not long ago (you'd need to undo
Helmut's fixes for that, I believe, to be able to reproduce that).

> I'm seriously tempted to suggest that until we can produce such a crash, we can work on the assumption that blocking signals while handling SIGSEGV is enough, but, again, I don't fully understand MPS and its complicated locking scheme.

I agree that having a reproduction recipe is a necessary condition for
trying to fix this.

> To expand a little on what I'm doing:
> 
> * install a handler for SIGUSR2 which dereferences a pointer stored in a global variable (and remove the old SIGUSR2 handler)
> * modify MPS's locking functions to kill(getpid(), SIGUSR2) right after acquiring the lock
> * in gdb, wait for a SIGSEGV to find a protected address/segment. Store that in the pointer variable.
> * there should now be a crash when the SIGUSR2 handler runs and memory protection for the pointer is in effect
> * no crashes observed so far.

Why not simply bind the sigusr2 event to some function (see the node
"Misc Events" in the ELisp manual for how), and then use "kill -USR2"
outside of Emacs?  IOW, I guess I don't understand why you'd need all
that complexity just to reproduce the crashes.