Re: MPS: a random backtrace while toying with gdb

[Pip Cet <pipcet@protonmail.com>]

On Monday, July 1st, 2024 at 18:08, Eli Zaretskii <eliz@gnu.org> wrote:
> > Date: Mon, 01 Jul 2024 17:27:49 +0000
>
> > From: Pip Cet pipcet@protonmail.com
> > Cc: eller.helmut@gmail.com, gerd.moellmann@gmail.com, yantar92@posteo.net, emacs-devel@gnu.org
>
> First, that queue was intended for more than just SIGCHLD.
>
> And second, depending on the OS, nested signals can or cannot be
> possible, so we need to take that into consideration.

I understand now, I think. Thank you.

> > One last suggestion: how about blocking those signals for most of Emacs' lifetime, only unblocking them in maybe_quit or at similar points? That would allow us to keep the existing signal handlers and make them safe...
>
> IMO, this would be the opposite of what we should do. We should have
> these signals blocked for as little time as possible, because
> otherwise the features built on them will be much less useful. For
> example, SIGUSR1/2 are a means of forcing Emacs out of some infinite
> loop which is otherwise uninterruptible -- if we let these signals be
> unblocked only in maybe_quit, we will have lost this useful feature.

Thanks for making that clear. That is a very useful feature and I would like to keep it. I'm also quite fond of the hourglass cursor :-)

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

> But if people who have time to work on that disagree, I have no means
> of making them do what they don't agree with.
>
> > I still think this is a simple oversight on the part of MPS, FWIW. You shouldn't allow other signals when handling SIGSEGV, or at least give the client program an option to specify a signal mask.
>
> 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'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.

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.

Pip