Re: MPS signals and Emacs

[Helmut Eller]

On Sun, Apr 21 2024, Paul Eggert wrote:

[..]
> Emacs's SIGBUS and SIGSEGV handlers are used only deal with serious
> internal fatal errors, which should never happen, and if they do
> happen I hope MPS will do the right thing with them by passing them to
> Emacs's thread_fatal_action. You should test that by injecting a
> serious internal fatal error (usage of a bad pointer) into Emacs and
> seeing that MPS does the right thing with it.

The code and the comment around line 100 in protsigx.c[*] suggests that
MPS is trying to do the right thing by invoking the previously installed
handler with:

  kill(getpid(), PROT_SIGNAL);

Where PROT_SIGNAL=SIGSEGV.  As the comment there explains, this does not
pass along the siginfo_t.  That of course means, that the previously
installed handler can't do much other than aborting (si_code will be 0).

I verified that this works, i.e. handle_sigsegv is actually called after
sigHandle when accessing address 0x4.

Whether this makes any sense in a multi-threaded setup; well, I'm not so
sure.

For the moment it's probably good enough but it will likely make
debugging bugs that aren't GC-related a bit harder.  In GDB it's already
necessary to say something like

  handle SIGSEGV nostop pass print

so that the process doesn't stop every time a memory barrier is hit.

I was also puzzled by the fact that during pdump, sigHandle worked fine
but later during loaddefs-gen not.  I then found this comment in
init_signals:

  /* Don't alter signal handlers if dumping.  On some machines,
     changing signal handlers sets static data that would make signals
     fail to work right when the dumped Emacs is run.  */
  if (will_dump_p ())
    return;

That explains the puzzling behavior but it makes me wonder what kind of
machine that could possibly be.  Also MPS clearly has to install memory
barriers, will_dump_p or not.  Will that affect those machines?

Helmut

[*] https://github.com/Ravenbrook/mps/blob/master/code/protsgix.c