[Top][All Lists]

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

Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc.

From: Paul Eggert
Subject: Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc.
Date: Sun, 3 Jan 2016 13:02:39 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0

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

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. It can be useful for the suspenders of stack-overflow checking to go along with the belt of must-be-perfect modules.

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.

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.

reply via email to

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