Re: Crash robustness (Was: Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc.)

[Eli Zaretskii]

> Cc: address@hidden, address@hidden,
>  address@hidden, address@hidden, address@hidden
> From: Daniel Colascione <address@hidden>
> Date: Wed, 23 Dec 2015 08:25:51 -0800
> 
> We can alloca, say, 8MB, and write to the start and end of the allocated
> region.

How do you know the alloca won't trigger stack overflow?

> Then we'll know we have at least that much stack space available.

At that point, yes.  But you need to know that at many other points,
when some of the stack is already used up.

> > I simply don't see any trouble this could cause, except leaking some
> > memory.  Can you describe in enough detail a single use case where
> > this could have any other adverse effects that we should care about
> > when recovering from stack overflow?
> 
> What happens if we overflow inside malloc? One possibility is that we'll
> longjmp back to toplevel without releasing the heap lock, then deadlock
> the next time we try to allocate.

I very much doubt anything like that can happen.  An malloc
implementation which behaves like that won't last long.  Lots of C
programs longjmp from signal handlers, so interrupting malloc with,
say, SIGINT, must work.  I think even Emacs did something like that in
the past, at least on a TTY, where C-g triggers SIGINT.

> >> We have a program that has its own Lisp runtime, has its own memory
> >> allocation system, uses its own virtual filesystem access layer, and
> >> that brings itself back from the dead. We're well past replicating OS
> >> functionality.
> > 
> > Actually, most of the above is simply untrue: we use system allocators
> > to allocate memory
> 
> We have internal allocators for strings and conses and use the system
> allocator only for backing storage.

On some systems.  Not on all of them.

> , and if by "bringing itself from the dead" you allude to
> > unexec, then what it does is a subset of what every linker does,
> > hardly an OS stuff.
> 
> Granted, that's toolchain work, not "OS" work, but it's still outside
> the domain of most text editors.

Sure.  But a linker is still an application that reads and writes
files.  It doesn't futz with OS-level features like page protection
and processor exceptions.

> > Emacs is not safety-critical software.  It doesn't need to be "safe"
> > by your definition, if I understand it correctly.
> 
> It's not safety-critical software, but undefined behavior is undefined.
> What makes us confident that we can't corrupt buffer data by longjmping
> from the wrong place?

Nothing makes us confident.  Recovery from stack overflow is not
guaranteed to work in all cases.  But if it works in some of them, it
is already better than always crashing, IMO.

> Anything can happen because we can longjmp from anywhere.

Yes.  But if we hit a stack overflow, we are already in deep trouble.

> What if we just installed a SIGSEGV handler (or, on Windows, a vectored
> exception handler) that wrote buffer contents to a special file on a
> fatal signal, then allowed that fatal signal to propagate normally?

I presume you mean auto-save, not save.

We could try calling shut_down_emacs from the signal handler, but I'm
not sure if the small alternate stack will be enough for write-region.
Something to investigate, I guess.

> The next time Emacs starts, we can restore the buffers we've saved
> this way and ask users to save them --- just like autosave, but done
> on-demand, at crash time, in C code, on the alternate signal stack.

Why "like autosave"?  What will be different from actually
auto-saving?  shut_down_emacs does that automatically.