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

[Daniel Colascione <dancol@dancol.org>]

[-- Attachment #1: Type: text/plain, Size: 1801 bytes --]

On 12/23/2015 10:09 AM, Eli Zaretskii wrote:
>> Cc: eggert@cs.ucla.edu, aurelien.aptel+emacs@gmail.com,
>>  p.stephani2@gmail.com, tzz@lifelogs.com, emacs-devel@gnu.org
>> From: Daniel Colascione <dancol@dancol.org>
>> Date: Wed, 23 Dec 2015 09:56:31 -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.

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.

You're against installing a guard page because it's something the OS
does. I don't see how that's relevant, since the OS gives us APIs
achieve exactly the behavior we want. The other objection to using a
guard page is that it requires determining in advance the maximum amount
of stack space we want to give Emacs, but if we limit it to 8MB on
Windows, 8MB of stack space should be enough anywhere.

Regardless, the current mechanism does not achieve its goal. It's
utterly unsafe even without module code added to the mix. A mechanism
that invokes arbitrary undefined behavior is *worse* than useless.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]