[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Crash robustness (Was: Re: Dynamic modules: MODULE_HANDLE_SIGNALS et
From: |
Eli Zaretskii |
Subject: |
Re: Crash robustness (Was: Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc.) |
Date: |
Wed, 23 Dec 2015 20:45:07 +0200 |
> 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.
- Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc., (continued)
- Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc., Eli Zaretskii, 2015/12/22
- 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 <=
- Re: Crash robustness (Was: Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc.), Daniel Colascione, 2015/12/23
- 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