Re: MPS: a random backtrace while toying with gdb

[Eli Zaretskii]

> Date: Wed, 03 Jul 2024 14:35:16 +0000
> From: Pip Cet <pipcet@protonmail.com>
> Cc: eller.helmut@gmail.com, gerd.moellmann@gmail.com, yantar92@posteo.net, 
> emacs-devel@gnu.org
> 
> > I'd start with the first half of (1). It is not clear to me that the
> > other part is needed, and in any case we need a reproducer for it
> > first.
> 
> Ihor's original SIGPROF-based reproducer works if you revert the 
> (SIGPROF-specific) workaround by Helmut. What makes you think it can't happen 
> with other signals (which, naturally, aren't as frequent or badly-timed as 
> SIGPROF, which strikes precisely when the CPU is active)?
> 
> Obviously a reproducer is highly desirable in this case, but we shouldn't 
> leave known and understood bugs in the code.

I agree, but you yourself said, and I agree, that without a test case
we cannot test any fixes in that area.  So let's have the text case
first and analyze it, before discussing solution.

> > Most of the crashes we've seen until now were not when the MPS
> > handler was running. Also, didn't someone say that when the MPS
> 
> Ihor's first crash backlog (MPS: profiler) clearly shows that was the case: 
> https://lists.gnu.org/archive/html/emacs-devel/2024-06/msg00568.html
> 
> > SIGSEGV handler is active, we could detect that from our code and
> > return doing nothing?
> 
> Dropping the signal in the process.

No, setting a flag to 'raise' the same signal when we are back in our
code and in safe environment (i.e., not called from the MPS SIGSEGV
handler).

Btw, an alternative would be to block the signals we care about while
in the MPS SIGSEGV handler in some way.  The way they install the
handler is very simple, see protsgix.c:ProtSetup.  Their code masks no
signals; we could instead mask the signals we care about.  As a POC,
I'd simply modify their code, but if that works, we could later
override their handler setup with ours or something.

> > Doing (2) adds a whole lot of complexity to Emacs.
> 
> You're right.
> 
> > Most importantly,
> > we will be unable to access Lisp data safely, unwind-protect and the
> > entire specpdl stuff generally cannot be used, and signaling an error
> > would be fatal. So I'd rather avoid that.
> 
> Very good points, though I wonder to what extent our current code is safe...

Well, I know from the MS-Windows experience that this is fraught with
pitfalls which took us some years to find and fix.  (On Windows, Emacs
uses additional threads for GUI I/O and for emulating SIGALRM and
SIGPROF.)