[Top][All Lists]

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

Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc.

From: Daniel Colascione
Subject: Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc.
Date: Sun, 3 Jan 2016 09:22:32 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0

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.

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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