Re: MPS: a random backtrace while toying with gdb

[Pip Cet <pipcet@protonmail.com>]

On Tuesday, July 2nd, 2024 at 14:57, Eli Zaretskii <eliz@gnu.org> wrote:
> > Date: Tue, 02 Jul 2024 14:24:33 +0000
> > From: Pip Cet pipcet@protonmail.com
> > Cc: eller.helmut@gmail.com, gerd.moellmann@gmail.com, yantar92@posteo.net, emacs-devel@gnu.org
> > 
> > > > > 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 finally figured out what I was doing wrong. I was allocating a few very large objects, but I needed many very small ones.

./emacs --batch -Q --eval "(progn (setq list nil) (keymap-set special-event-map \"<sigusr1>\" (lambda () (interactive) (length list))) (while t (push nil list)))" & while sleep .1; do kill -USR1 %%; done

works.

> > 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?
> 
> 
> I don't think they all were interrupting MPS's SIGSEGV handler. I
> think it's the other way around: we interrupted MPS code, and our
> signal handler accessed memory which triggered MPS's SIGSEGV.

You're correct.

> But even if I'm wrong, why is that important? We need to solve both
> kinds of situations, don't we?

Now that we have a way to reproducibly make it happen, yes, I agree.

> > > 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.
> 
> Not AFAICT. Look:

I did, now. You're right.

> . we called Fcons (from a "normal" Emacs Lisp program, which called
> set-face-attribute)
> . that entered MPS by way of igc_make_cons
> . MPS called our scanning code in dflt_scan
> . while in fix_* functions called by dflt_scan, we got SIGCHLD
> . the SIGCHLD handler accessed Lisp data of the process object(s),
> which triggered MPS SIGSEGV handler
> . the MPS handler tried to take the arena lock and aborted
> 
> IOW, SIGCHLD did NOT interrupt the MPS SIGSEGV handler, it interrupted
> the "normal" MPS code when it called our scanning callbacks.

You're right, again.

> > > 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.
> 
> I think the scenario above with SIGCHLD does precisely that, no?

It does.

Pip