emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc.


From: Eli Zaretskii
Subject: Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc.
Date: Tue, 22 Dec 2015 22:46:26 +0200

> Cc: address@hidden, address@hidden,
>  address@hidden, address@hidden, address@hidden
> From: Daniel Colascione <address@hidden>
> 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.

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.

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]