Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc.

[Daniel Colascione <dancol@dancol.org>]

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

On 12/22/2015 12:46 PM, 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: Tue, 22 Dec 2015 12:31:58 -0800
>>
>>> 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
> 
> If you only longjmp a short while, you have no idea how much stack you
> freed.  You might as well be just 200 bytes below the level where the
> stack overflow hit.

Which is why you setjmp in places where you have a significant stack
reserve.

> That's why we jump to the lowest level we can: there, we _know_ we
> have enough stack to do any kind of stuff.
> 
>>> 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.
> 
> No, the core isn't in a bad state.  Longjmp is not an abnormal path,
> its semantics is very simple and clear.

Longjmp, by itself, is simple and clear. What's unreliable is longjmping
to Lisp at completely arbitrary points in the program, even ones marked
"GC can't happen here" and the like. You say Emacs shouldn't crash.
Fine. We can't make that guarantee if the crash recovery code breaks
program invariants. If you want to longjmp, you need to do it at certain
well-defined points only. The current approach is a bug machine.

>> We can gracefully recover from stack overflow of Lisp code. We
>> cannot recover from stack oveflow at arbitrary points in the C core.
> 
> We can and we do.  The recovery has only to be good enough to allow
> saving your work and exiting.  That's the only goal of that
> protection: allow the user to exit normally, after saving their work.

I'd rather rely on autosaves. Failing that, we should allocate guard
pages, unprotect the guard pages on overflow, and call out_of_memory so
that it's obvious Emacs is in a bad state. This way, we don't have to
longjmp out of arbitrary code sequences.


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