Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc.

[Daniel Colascione]

On 01/03/2016 09:16 AM, Eli Zaretskii wrote:
>> From: Paul Eggert <address@hidden>
>> Date: Sun, 3 Jan 2016 08:31:35 -0800
>>
>> Daniel Colascione wrote:
>>> In 2014, Emacs gained a new path in the SIGSEGV handler that attempts to
>>> detect C stack oerflow and longjmp back to toplevel. It's important to
>>> note that we don't just longjmp when we're in a safe position: we
>>> longjmp from *anywhere*, even if we're, say, in the middle of malloc.
>>
>> Although that particular code path may have been introduced recently, for 
>> decades Emacs has longjmped from arbitrary locations due to other signals, 
>> so 
>> adding a longjmp for SIGSEGV does not introduce new issues.
>>
>>> The code is fundamentally flawed and cannot be made to work
>>> properly on any platform.
>>
>> The code is part of Emacs 24.5 and does not appear to be causing problems; 
>> at 
>> least, I don't recall any bug reports from the field. The other longjmps, 
>> which 
>> are fundamentally flawed in the same way, have been in Emacs for decades, 
>> and 
>> also seem to work well enough in practice.
> 
> All true.

Untrue. Which jumps in particular can come from inside malloc?

> But we are reiterating a long discussion, where all of this was
> already said, and said again, and again, and again.  There's nothing
> new left to be said here.
> 
> Daniel thinks that Emacs should be designed and implemented as
> safety-critical software, where any such techniques are a definite
> no-no.  But Emacs is not a safety-critical program, it is allowed to
> crash from time to time, even in nasty ways.  It is therefore okay for
> such a program to use techniques that make the probability of losing
> work lower.  My analysis of this discussion is that this is the
> crucial point that Daniel refuses to understand and/or agree to --
> that being a non safety-critical piece of software means Emacs can do
> stuff that it otherwise would have been prohibited from doing.

It's not about whether Emacs is "safety critical" --- it's about whether
you're making the robustness situation worse than it already is by
adding dubious workarounds for a problem we don't actually have.

The Linux kernel doesn't bill itself as safety critical either, and this
kind of reckless sloppiness wouldn't be acceptable there either.

> IOW, a requirement as fundamental as safety-criticality _does_ affect
> the design and the techniques allowed during implementation.  I submit
> that this is a fundamental software engineering issue which cannot be
> cast away, and as long as Daniel misinterprets it, we can never agree
> on anything.  Because in safety-critical software, even a single nasty
> crash can be fatal, something that is very far from what Emacs can do.

You're creating a false dichotomy between safety-critical software and
everything else. Emacs merely not avionics-grade software does not
excuse the use of techniques that are both inherently incorrect and that
add no real value and quite a bit of real danger.

You have *still* not presented any evidence, not one shred, that we have
a real stack overflow problem that makes it worth relying on more than
the auto-save functionality and that makes it worth reaching for unsafe
and completely undefined behavior.

All you have is your assertion that Emacs is not safety-critical
software, we can should use this technique, which you have not
demonstrated saves anyone anything and which I have demonstrated is
completely unsafe.

signature.asc
Description: OpenPGP digital signature