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

[Daniel Colascione <dancol@dancol.org>]

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

On 12/23/2015 10:45 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 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.

So make it bullet-proof and very dumb: add a bit of C code that visits
all buffers and writes their contents to a file we've pre-opened (so we
have a file descriptor handy). On the next startup, read that file and
restore the buffers.

I don't think that measure is necessary though, since we already deal
with stack overflow of Lisp in other ways. What convinces you that stack
overflow of C code is a real problem?

>> 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.

It depends on how many of them you want to have. After all, until
they're used, they consume only address space. (That's true on Windows
as well.)

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

It does not.


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