Re: MPS: a random backtrace while toying with gdb

[Eli Zaretskii <eliz@gnu.org>]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: Helmut Eller <eller.helmut@gmail.com>, gerd.moellmann@gmail.com,
>  pipcet@protonmail.com, emacs-devel@gnu.org
> Date: Sun, 30 Jun 2024 21:08:48 +0000
> 
> If my understanding is correct, the situation we have is when MPS is
> performing root scan while also receiving another signal. During the
> root scan, all other Emacs threads are suspended, and no state changes
> are taking place - everything is locked by MPS thread, which is the only
> thread running.
> 
> Emacs signal handlers are, of course, installed for all the threads. And
> since the only thread being running is MPS thread - it will be the one
> handling the received signal. And the handler thus cannot run normally,
> reaching out to the MPS-managed memory as usual.
> 
> So, we should somehow arrange the handler to wait until the MPS scan
> finishes and the actual Emacs threads are resumed.
> Such waiting should not lose any information as the actual Emacs state
> is not going to change during the scan.
> 
> The simplest way to do it is setting up a mask for MPS
> thread. (Although, we may or may not want to do it for profiler signals
> specifically, depending on whether these signals will be queued by the OS
> or merged into a single signal before unblocking - merging will make us
> loose some samples)

As I wrote earlier, these last crashes happened when the only thread
running was the Emacs main thread, and MPS code was called from that
thread, as side effect of allocating memory (AFAIU).  So the situation
with multiple threads is not what we see here.

Nevertheless, please note that Emacs has machinery to deliver signals
on the main thread, see deliver_process_signal (and be sure to read
the commentary of that function).  So if this is needed, we seem to
already have the code in place to deal with it.