Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc.

[Daniel Colascione <dancol@dancol.org>]

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

On 01/03/2016 01:02 PM, Paul Eggert wrote:
> Daniel Colascione wrote:
> 
>> neither you nor Eli have demonstrated in any way that all this
>> complexity is necessary, that we actually have a C stack overflow
>> problem,
> 
> I mentioned (1) stack overflow in the regexp code, and (2) stack
> overflow in C modules; did you miss that? The counterargument for (2)
> that C modules can crash Emacs in countless ways so let's not worry
> about stack overflow is not all that convincing.

I think it's very convincing, and it's even less defensible to try to
fix overflows in modules. It's *critical* not to violate the invariants
of code. You have no idea what might happen when you do. It's not the
job of the Emacs core to try to fix the bugs in modules that happen to
be loaded into the process.

> It can be useful for
> the suspenders of stack-overflow checking to go along with the belt of
> must-be-perfect modules.

As I've previously written, I don't believe in trying to paper over
bugs. Just crash. Loading native code in Emacs is a dangerous operation;
trying to hide that danger by attempting to fix certain classes of
module bugs will just make all problems harder to find.

>> 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.
> 
> Ah, good point, so that part of the code should be OK. Still, a few
> lines earlier we see things like Fdo_auto_save () and fflush (stdout)
> that can be executed from a Unix signal handler while quit-flag is
> non-nil. Although this has undefined behavior too, this code has been
> around for quite some time and I use it more often than I like to admit.

I don't like this either. It should be possible to replace the printfs
in this instance with calls to write(1, "message") (which will bypass
any output buffering) and restore async-signal-safety.

If a user elects to attempt auto-save in this situation, that's on him.
Ideally, we'd make autosave async-signal-safe, which will help in this
handler and in the segfault hander.

>> 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 think something along that lines would suffice, yes. Admittedly I
> didn't quite follow what you wrote (perhaps some text got elided?). But
> the main point, as I understand it, is that we needn't worry about
> having a stack-overflow check inside the stack-overflow handler, because
> we can insist that the stack-overflow handler be tightly-enough
> controlled so that it won't recurse indefinitely.

Yes: do as little as possible in the segfault handler and signal an
error the normal way at the next safe opportunity, if one arises before
we fully exhaust the stack.


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