Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc.

[Paul Eggert <eggert@cs.ucla.edu>]

Daniel Colascione wrote:
> In 2014, Emacs gained a new path in the SIGSEGV handler that attempts to
> detect C stack oerflow and longjmp back to toplevel. It's important to
> note that we don't just longjmp when we're in a safe position: we
> longjmp from *anywhere*, even if we're, say, in the middle of malloc.

Although that particular code path may have been introduced recently, for 
decades Emacs has longjmped from arbitrary locations due to other signals, so 
adding a longjmp for SIGSEGV does not introduce new issues.

> The code is fundamentally flawed and cannot be made to work
> properly on any platform.

The code is part of Emacs 24.5 and does not appear to be causing problems; at 
least, I don't recall any bug reports from the field. The other longjmps, which 
are fundamentally flawed in the same way, have been in Emacs for decades, and 
also seem to work well enough in practice.

> No other program attempts to recover from
> stack overflow this way.

True, not *exactly* in this way, but Emacs is pretty special.

> In practice, the Lisp stack depth limits provide enough protection

That won't be true once once people link in dynamic modules, since the modules 
may not use Lisp and may exhaust the C stack. And even without modules, I recall 
people running into stack-overflow issues in the regular-expression code. Did 
that ever get fixed? Even if so, most likely other such issues are still lurking 
in the regexp code.

> The existing auto-save logic
> is good enough for data recovery, especially if we run the sigsegv
> handler on the alternate signal stack (which we can make as large as we
> want) when possible.

Something like that could help, yes. But the existing auto-save logic can 
longjmp out, so I don't see how this would address your concern about longjmp.

One possible way forward here is the approach recommended by GNU libsigsegv. See 
<https://www.gnu.org/software/libsigsegv/> "About stack overflow handlers". In 
the past we've avoided libsigsegv's approach because it was considered to be too 
heavyweight, but it would be safer to do something along the lines that it 
suggests, or perhaps even to use libsigsegv if available.

> If we keep this code in Emacs, it sets a precedent for other terrible
> forms of crash recovery, like silently ignoring writes to NULL ...

Naah. We're pragmatic, not stupid.