Re: MPS: a random backtrace while toying with gdb

[Pip Cet <pipcet@protonmail.com>]

On Tuesday, July 2nd, 2024 at 13:10, Eli Zaretskii <eliz@gnu.org> wrote:
> > 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.

Agreed.

> > > 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?

Those were all signals interrupting MPS's SIGSEGV handler. You were talking about signals interrupting MPS code that runs outside of a signal handler, weren't you?

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

Same thing.

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

Excellent.

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

Because I wanted to be sure to hit the tiny window while a global lock was taken.

Pip