Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc.

[Daniel Colascione]

On 01/03/2016 03:11 PM, Paul Eggert wrote:
> Daniel Colascione wrote:
>> It's *critical* not to violate the invariants of code.
> 
> Sure, but we are discussing what those invariants should be; they are
> not carved in stone.  One possible invariant is (A) "stack overflow
> never happens". Another is (B) "if stack overflow happens, callers must
> tolerate being longjmped through". Either invariant is reasonable per
> se. It is a judgment call as to which invariant is better for Emacs.
> Possibly some modules will prefer (A) and others (B).
> 
> Take the regular expression code as an example. Suppose it has unusual
> worst-case behavior that can grow the stack in arbitrary ways (which I
> think it does though I'm not going to investigate the details right
> now). One way to address this is to rewrite the code so that it doesn't
> have the behavior, but that would be a pain; the code has been that way
> for decades and is crufty at this point and a lot of Emacs depends on
> its quirks. Another way to address it is to use a guard page or whatever
> on the halfway-decent platforms that support that sort of thing. We've
> chosen the latter, i.e., we've chosen invariant (B), and yes there are
> problems with this approach but it beats doing nothing and it beats
> doing (A) because nobody has had the time to do (A), assuming it's
> doable at all.

The regexp code is a good example of a benign use of longjmp. That's our
code and we know it pretty well. We can set a global variable that says
"longjmp if there's a stack overflow in *this* piece of code" without
longjmping out of arbitrary pieces of code we don't own. GDB uses a
similar approach to suppress crashes from C++ demangling code.

>> 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.
> 
> Good point. I did that with the attached patch to emacs-25. However,
> this doesn't address the Fdo_auto_save () issue in the same neighborhood.

Thanks. The quick and dirty fix for Fdo_auto_save is to run
Fdo_auto_save in a forked child, where it's less likely to hurt
something, and put a limit on the time we're prepared to spend waiting
for that child. I've implemented Breakpad extensions that use a similar
approach to good effect. Of course, this approach won't work for
Windows, DOS, etc., but we're talking about quick and dirty.

>> If a user elects to attempt auto-save in this situation, that's on him.
> 
> Sure, and Emacs already asks the user whether to auto-save in that
> situation, so this should be OK already.

I'm not sure users on window systems actually see these prompts. IME,
that's the majority of users.

>> Ideally, we'd make autosave async-signal-safe, which will help in this
>> handler and in the segfault hander.
> 
> Yes, that'd be good, if we didn't lose functionality thereby.

It's the functionality loss that prompts me to propose a simpler,
pure-C, non-Fdo_auto_save approach to saving data when we're crashed;
see the other branch of this thread.

signature.asc
Description: OpenPGP digital signature