On 01/03/2016 10:07 AM, Paul Eggert wrote:
> Daniel Colascione wrote:
> 
>> we don't respond to *unix* signals by longjmping.
> 
> Not true. A code path is deliver_interrupt_signal →
> deliver_process_signal → handle_interrupt_signal → handle_interrupt →
> quit_throw_to_read_char → sys_longjmp.

Not the case. handle_interrupt can call quit_throw_to_read_char only
when waiting_for_input is true, which it is only when, well, we're
waiting for input, not at arbitrary points in the program.

It can't be the case that we can longjmp from arbitrary points in Emacs
in response to a SIGINT, since if we did, C-g would be unsafe and could
crash Emacs, which it doesn't.

> For what it's worth, Emacs can
> also lisp-signal from Unix signal handlers if immediate_quit is true.
> This code has been in Emacs for many years.

Likewise. Any call to malloc (or, in general, any async-signal-unsafe
function) with immediate_quit or waiting_for_input true is a bug that we
need to fix.

Longjmp from a signal handler isn't a bad approach. I use it in my own
programs. It becomes abominable when the longjmp can happen from
*anywhere*, as it can with the stack overflow handler.

>> The libsigsegv approach is a problem too: pthread cancellation in
>> practice is unsupported on some platforms, does not execute C++
>> destructors on some platforms even where it's supported, is lightly
>> tested, and conflicts with other uses of sigsegv. In the case of Emacs,
>> pthread cancellation is additionally risky because we don't even try to
>> PTHREAD_CANCEL_DISABLE around critical code sequences.
> 
> Yes, of course we'd have to do some work to take the libsigsegv
> approach. We would need to use pthread cancellation only on platforms
> where it works, and we would need to defer cancellation during critical
> sections. On platforms that lack pthread cancellation or where it
> doesn't work, we'd be no worse off than we are now. If we do the longjmp
> ourselves I assume we can work around the C++ destructor problem the
> same way we do now.

Or can we use a stack guard region [1], and in the signal handler,
unprotect the set a global variable in the signal handler, and check the
variable on QUIT, and at toplevel, reprotect the guard region. If we
segfault again without having reached toplevel, just die. Would that
make you happy? I'd much rather see that approach, which is safe, than
our current one, which isn't.

[1] If I say "guard page", the conventional term, you'll complain that a
single page isn't sufficient.

> From what Eli writes, some of this work (I don't know how much) has
> already been done for the MS-Windows port. It would be helpful to do
> something similar for GNU/Linux and similar platforms, and to do it
> right by marking critical sections etc. All this would make Emacs more
> bullet-proof, if someone has the time to undertake the job.

I haven't looked as much at the Windows stack overflow implementation,
but there's clearly nothing in the code right now that establishes the
critical regions necessary for this scheme to work. Besides, this scheme
*still* leaves you vulnerable to stack overflow, since if you overflow
in a cancellation-disable region, your only option is to crash.

Again, neither you nor Eli have demonstrated in any way that all this
complexity is necessary, that we actually have a C stack overflow
problem, or that we have special needs that other text editors and user
programs don't, needs that justify an elaborate stack overflow recovery
scheme.