[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc.
From: |
Daniel Colascione |
Subject: |
Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc. |
Date: |
Tue, 22 Dec 2015 12:31:58 -0800 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 |
On 12/22/2015 08:01 AM, Eli Zaretskii wrote:
>> Cc: address@hidden, address@hidden, address@hidden,
>> address@hidden
>> From: Daniel Colascione <address@hidden>
>> Date: Mon, 21 Dec 2015 20:38:07 -0800
>>
>> Right now, when we get a SIGSEGV, we check the siginfo_t the OS gives us
>> by calling stack_overflow on it; if that returns true, we longjmp to
>> toplevel. We configure the sigsegv handler to run on an alternate stack,
>> so we'll always have space to do that much work. The longjmp restores
>> the original stack. On the other side of the longjmp, we resume
>> execution with our regular stack, but much further up the stack. At this
>> point, we know we have a stack overflow, because nothing else longjmps
>> to return_to_command_loop.
>>
>> Now, if we return normally to a C++ caller with an error indication set,
>> the C++ caller will almost certainly have enough stack space to throw
>> its own exception and propagate the exception further.
>
> I very much doubt that. The alternate stack is quite small (AFAIK,
> the standard value that we are using, SIGSTKSZ, is something like
> 8KB). Running arbitrary C++ code on such a small stack is not safe.
> (My understanding is that the value of SIGSTKSZ should suffice for
> calling printf, and that's about it.) There will be high risk of
> hitting yet another stack overflow, this time a fatal one.
We're not talking about running arbitrary C++ code on the small stack.
The longjmp transfers execution to the original stack, but with the
context popped off.
Overflow stack: A B C D E F G
Signal stack: 1 2 3 longjmp
Resumption stack: A B C
>
>> unwind_to_catch isn't really very different from the longmp to
>> return_to_command_loop: I don't see any reason we can't run it on the
>> alternate signal stack. In fact, I don't see why we can't replace
>> return_to_command_loop generally with Fsignal.
>
> See above: I think running arbitrary Lisp code on a 8KB stack is even
> less safe that with C++ code. We avoid doing that for a good reason.
> Let me remind you that Emacs on Windows sets up a 8MB stack (as
> opposed to the standard 2MB) because it is necessary in some
> situations, like matching some regexps. 8MB, not 8KB! A Lisp unwind
> handler can do anything at all, so I think running the unwinding code
> from a stack overflow is not an option, if we want to make sure stack
> overflow recovery will not hit another fatal stack overflow in most
> cases.
>
>> I really don't like the stack overflow protection stuff in general
>> though. It's not possible to robustly recover, because the stack
>> overflow detection turns *any* function call into an operation that
>> might return non-locally. In that environment --- where, say, XCAR might
>> end up running lisp --- it's hard to maintain invariants.
>
> It might be less than nice or elegant, but Emacs should give the user
> an opportunity to save their work.
>
>> I'd rather Emacs just die on C stack overflow, except when we know
>> we're running Lisp in such a way that we know we can recover.
>
> You are in effect saying the stack overflow recovery code should not
> have been added to Emacs. But we already decided that an attempt to
> recover is a useful feature, and I see no reason to go back. Even if
> this is works only in some cases, partial recovery is better than a
> hard crash, because it lets users save their work.
Or it actually corrupts their work, because the Emacs core is in a bad
state. We can gracefully recover from stack overflow of Lisp code. We
cannot recover from stack oveflow at arbitrary points in the C core.
signature.asc
Description: OpenPGP digital signature
- Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc., (continued)
- Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc., Paul Eggert, 2015/12/22
- Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc., Eli Zaretskii, 2015/12/22
- Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc., Paul Eggert, 2015/12/22
- Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc., Eli Zaretskii, 2015/12/23
- Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc., Philipp Stephani, 2015/12/23
- Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc., Eli Zaretskii, 2015/12/23
- Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc., Paul Eggert, 2015/12/23
- Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc., Daniel Colascione, 2015/12/23
- Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc., Eli Zaretskii, 2015/12/22
- Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc., John Wiegley, 2015/12/22
- Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc.,
Daniel Colascione <=
- 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/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