[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Crash robustness (Was: Re: Dynamic modules: MODULE_HANDLE_SIGNALS et
From: |
Daniel Colascione |
Subject: |
Re: Crash robustness (Was: Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc.) |
Date: |
Wed, 23 Dec 2015 19:26:25 -0800 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 |
On 12/23/2015 10:45 AM, Eli Zaretskii wrote:
>> 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.
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.
signature.asc
Description: OpenPGP digital signature
- Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc., (continued)
- Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc., Daniel Colascione, 2015/12/22
- Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc., Eli Zaretskii, 2015/12/23
- Crash robustness (Was: Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc.), Daniel Colascione, 2015/12/23
- Re: Crash robustness (Was: Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc.), Eli Zaretskii, 2015/12/23
- Re: Crash robustness (Was: Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc.), Daniel Colascione, 2015/12/23
- Re: Crash robustness (Was: Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc.), Eli Zaretskii, 2015/12/23
- Re: Crash robustness (Was: Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc.), Daniel Colascione, 2015/12/23
- Re: Crash robustness (Was: Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc.), Eli Zaretskii, 2015/12/23
- Re: Crash robustness (Was: Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc.), Daniel Colascione, 2015/12/23
- Re: Crash robustness (Was: Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc.), Eli Zaretskii, 2015/12/23
- Re: Crash robustness (Was: Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc.),
Daniel Colascione <=
- Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc., Eli Zaretskii, 2015/12/21
- Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc., Philipp Stephani, 2015/12/21
Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc., Eli Zaretskii, 2015/12/20