Re: Crash robustness (Was: Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc.)

[Eli Zaretskii]

> Cc: address@hidden, address@hidden,
>  address@hidden, address@hidden, address@hidden
> From: Daniel Colascione <address@hidden>
> Date: Wed, 23 Dec 2015 10:19:15 -0800
> 
> >>>> We can make the alternate signal stack as large as we want.
> >>>
> >>> Not as large as is safe to run arbitrary Lisp.
> >>
> >> Then don't run arbitrary lisp after we've segfaulted.
> > 
> > It's out of your control.
> 
> No it isn't. We don't have to run the generic auto-save logic: in fact,
> we probably shouldn't run arbitrary lisp, because a fatal signal
> indicates that the process is in a bad state. Instead, if we really want
> to minimize the possibility of data loss, we should use a pure-C
> autosave system directly from the crash handler, not longjmp from
> arbitrary parts of the program to toplevel.

auto-save is implemented in C anyway.  But it calls functions that
might call Lisp out of your control.  We attempt to disable that when
in emergency shutdown, but it's not bullet-proof.

And there still is a problem of buffers that don't visit files.

> The other option is to use a guard page: on stack overflow, unprotect
> the guard page (allowing program execution to proceed normally for a
> little while longer --- again, no longjmp), Fsignal at the next
> opportunity to QUIT, invoke out_of_memory after the signal, and let
> users save at that point.

The guard page is too small for any serious code.

> Regardless, the current mechanism does not achieve its goal.

Of course, it does.

> A mechanism that invokes arbitrary undefined behavior is *worse*
> than useless.

I cannot disagree more.