On Tue, 17 Nov 2009 02:51:13 -0800, Walter Bright
<newshound1@digitalmars.com> wrote:
>
>I suppose nobody much cares if it writes out a corrupted audio file.
>People care very much if their airplane suddenly dives into the ground.
>
>Be that as it may, it is certainly possible to catch seg faults in an
>exception handler and write files out. That would be an unacceptable
>behavior, though, in a system that needs to be safe.
Yeah, you are right. It was just one example where continuing the
execution after failure makes sense.
>> Then, instead of sticking with Windows and the likes, you may want to
>> think about porting dmd to a more serious environment specifically
>> designed for developing such systems. What about a real-time
>> microkernel OS like this one:
>> http://www.qnx.com/products/neutrino_rtos/ ?
>
>dmd targets Windows because that's where probably half the programmers
>are. I'd certainly like to do embedded systems, too, but realistically
>that's going to be the purview of gdc or ldc.
Ok.

Andrei Alexandrescu Wrote:
> Sean Kelly wrote:
> > Tomas Lindquist Olsen Wrote:
> >
> >> On Tue, Nov 17, 2009 at 11:51 AM, Walter Bright
> >> <newshound1@digitalmars.com> wrote:
> >>> I suppose nobody much cares if it writes out a corrupted audio file. People
> >>> care very much if their airplane suddenly dives into the ground.
> >>>
> >>> Be that as it may, it is certainly possible to catch seg faults in an
> >>> exception handler and write files out. That would be an unacceptable
> >>> behavior, though, in a system that needs to be safe.
> >>>
> >> You spent quite a bit of effort explaining that segfaults never cause
> >> memory corruption, so it seems fairly reasonable to assume that some
> >> parts of the application state could still be valid and useful not to
> >> throw away.
> >
> > At the moment the segfault occurs, sure. But if the process eats the segfault and continues, what happens? If an app is programmed in such a way that segfaults are a part of normal processing (I worked on a DB that performed dynamic loading this way) that's one thing. But other apps are almost definitely going to try and write data near 0x00 after such an occurrence.
>
> I think throwing an Error object instead of failing immediately would be
> occasionally useful. (Same goes about other trapped errors such as
> integral division by zero.) There are applications out there that want
> to partially recover from a null pointer error. I wrote a few, so it's
> difficult to convince me they don't exist.
I'd love to! And this is how Windows works. But throwing an exception from a signal handler invokes undefined behavior. Last time I googled this I saw as many accounts of it failing horribly as working.

Hello Walter,
> Tomas Lindquist Olsen wrote:
>
>> You spent quite a bit of effort explaining that segfaults never cause
>> memory corruption, so it seems fairly reasonable to assume that some
>> parts of the application state could still be valid and useful not to
>> throw away.
>>
> When a seg fault occurs, it is because your program is in a state that
> you, the programmer, never anticipated. Therefore, you cannot know
> what state your data is in. Therefore, your data is unreliable. While
> it may not be in a bad state from memory corruption, it could very
> well be in a bad state from your program's logic being wrong.
>
> Do you want to bet your life on assuming your program and its data is
> still valid?
No, at that point I wouldn't count on the program doing any thing correctly.
But that is a long way from trying to get it to do something useful on the
way down, like try and save off what data it can and generate a crash log
with whatever it can salvage. If either of these fail, I'm, at worst, in
exactly the same position I was in before I attempted them and, at best,
they work.
And before you say it, if the system is truly critical, I'd have the crash
handler in ROM, a hardware lock out to stop the system from mucking with
any thing external and a watchdog timer to reset it if the crash handler
hangs.

Hello Walter,
> Max Samukha wrote:
>
>> On Mon, 16 Nov 2009 12:48:51 -0800, Walter Bright
>> <newshound1@digitalmars.com> wrote:
>>> If you've got a system that relies on the software continuing to
>>> function after an unexpected null seg fault, you have a VERY BADLY
>>> DESIGNED and COMPLETELY UNSAFE system. I really cannot emphasize
>>> this enough.
>>>
>> I have an example of such a software:
>> http://www.steinberg.net/en/products/audiopostproduction_product/nuen
>> do4.html
>> It loads third-party plugins into the host process's address space,
>> an consequently it may fail at any moment. The software's design is
>> not the best ever but it gives the user last chance to save his work
>> in case of fatal error. This feature has saved my back a couple of
>> times.
>>
>
> Be that as it may, it is certainly possible to catch seg faults in an
> exception handler and write files out. That would be an unacceptable
> behavior, though, in a system that needs to be safe.
>
For some systems, once you hit a seg-v, things can't get any worse so why
not try to make things better by saving what you can?

BCS wrote:
> For some systems, once you hit a seg-v, things can't get any worse
Oh, yes they can! You could now be executing a virus. *Anything* the
software is connected to can now do anything wrong or malicious.
(On my car, I installed an oil pressure switch that shuts off the
electric fuel pump if the pressure drops. I also pried a switch off of a
junkyard Mustang that shuts off if it gets hit hard, I also plan on
installing that to shut off the fuel pump. Think of those like a "seg
fault" <g>)
> so why not try to make things better by saving what you can?
Sure, you can try saving things, but you'd better hope that there was
already a reasonably recent clean copy of your data.
To write safe & reliable software, approach it from "what can go wrong,
will go wrong", not "I won't worry about that case, because it's unlikely."

Hello Walter,
> BCS wrote:
>
>> For some systems, once you hit a seg-v, things can't get any worse
>>
> Oh, yes they can!
For some cases they can, for others they can't.
> You could now be executing a virus. *Anything* the
> software is connected to can now do anything wrong or malicious.
> (On my car, I installed an oil pressure switch that shuts off the
> electric fuel pump if the pressure drops.
It might not translate to CS but there are good reasons that such a device
doesn't come standard on cars; the first time one killed a car in rush hour
traffic and set off a 50 car pile-up the someone (GM?) goes bankrupt.
> I also pried a switch off of
> a junkyard Mustang that shuts off if it gets hit hard, I also plan on
> installing that to shut off the fuel pump. Think of those like a "seg
> fault" <g>)
That one might even be worse because it only comes into play when you know
things are going wrong; "as soon as things go wrong, my car quits working".
>
>> so why not try to make things better by saving what you can?
>>
> Sure, you can try saving things, but you'd better hope that there was
> already a reasonably recent clean copy of your data.
that or make a very robust dump system (core dump?)
> To write safe & reliable software, approach it from "what can go
> wrong, will go wrong", not "I won't worry about that case, because
> it's unlikely."

BCS wrote:
>> (On my car, I installed an oil pressure switch that shuts off the
>> electric fuel pump if the pressure drops.
> It might not translate to CS but there are good reasons that such a
> device doesn't come standard on cars; the first time one killed a car in
> rush hour traffic and set off a 50 car pile-up the someone (GM?) goes
> bankrupt.
With the pump shut off, you have a few seconds of fuel left in the carb.
With no oil pressure, your engine is going to seize anyway.
>> I also pried a switch off of
>> a junkyard Mustang that shuts off if it gets hit hard, I also plan on
>> installing that to shut off the fuel pump. Think of those like a "seg
>> fault" <g>)
>
> That one might even be worse because it only comes into play when you
> know things are going wrong; "as soon as things go wrong, my car quits
> working".
You *really* don't want your fuel pump to keep on pumping if you're in
an accident. That's the purpose of the inertial switch. With older
mechanical pumps, the pump would stop whenever the engine did. The
gasoline is safer remaining in the tank than being pumped all over the
road, the hot engine, and your trapped body.
>>> so why not try to make things better by saving what you can?
>>>
>> Sure, you can try saving things, but you'd better hope that there was
>> already a reasonably recent clean copy of your data.
>
> that or make a very robust dump system (core dump?)
A core dump, no matter how robust, will not fix your data if it is
randomized by an errant program before it seg faulted.
>> To write safe & reliable software, approach it from "what can go
>> wrong, will go wrong", not "I won't worry about that case, because
>> it's unlikely."
>
>

Hello Walter,
> BCS wrote:
>
>>> (On my car, I installed an oil pressure switch that shuts off the
>>> electric fuel pump if the pressure drops.
>>>
>> It might not translate to CS but there are good reasons that such a
>> device doesn't come standard on cars; the first time one killed a car
>> in rush hour traffic and set off a 50 car pile-up the someone (GM?)
>> goes bankrupt.
>>
> With the pump shut off, you have a few seconds of fuel left in the
> carb. With no oil pressure, your engine is going to seize anyway.
In a few minutes yes (and it will still run for some time after it's damaged
beyond repair), more than long enough off get off the road. I'd put a big
buzzer in and let the driver decide when it is safe to shut down the engine.
In some situations, I'd gladly cook the engine to get to safety.
>
>>> I also pried a switch off of
>>> a junkyard Mustang that shuts off if it gets hit hard, I also plan
>>> on
>>> installing that to shut off the fuel pump. Think of those like a
>>> "seg
>>> fault" <g>)
>> That one might even be worse because it only comes into play when you
>> know things are going wrong; "as soon as things go wrong, my car
>> quits working".
>>
> You *really* don't want your fuel pump to keep on pumping if you're in
> an accident. That's the purpose of the inertial switch. With older
> mechanical pumps, the pump would stop whenever the engine did. The
> gasoline is safer remaining in the tank than being pumped all over the
> road, the hot engine, and your trapped body.
So tie it into the inition system or a tilt switch (some 4x4 do that one).
>>>> so why not try to make things better by saving what you can?
>>>>
>>> Sure, you can try saving things, but you'd better hope that there
>>> was already a reasonably recent clean copy of your data.
>>>
>> that or make a very robust dump system (core dump?)
>>
> A core dump, no matter how robust, will not fix your data if it is
> randomized by an errant program before it seg faulted.
>
Who said anything about fixing stuff? I've been thinking only of logging
and a recover-your-work,-maybe file kinds of things.
I agree, any more than that won't work.

BCS wrote:
>> With the pump shut off, you have a few seconds of fuel left in the
>> carb. With no oil pressure, your engine is going to seize anyway.
>
> In a few minutes yes (and it will still run for some time after it's
> damaged beyond repair), more than long enough off get off the road. I'd
> put a big buzzer in and let the driver decide when it is safe to shut
> down the engine. In some situations, I'd gladly cook the engine to get
> to safety.
There is an override on the switch to turn the pump on anyway, but it's
a push button you have to hold down.
>>>> I also pried a switch off of
>>>> a junkyard Mustang that shuts off if it gets hit hard, I also plan
>>>> on
>>>> installing that to shut off the fuel pump. Think of those like a
>>>> "seg
>>>> fault" <g>)
>>> That one might even be worse because it only comes into play when you
>>> know things are going wrong; "as soon as things go wrong, my car
>>> quits working".
>>>
>> You *really* don't want your fuel pump to keep on pumping if you're in
>> an accident. That's the purpose of the inertial switch. With older
>> mechanical pumps, the pump would stop whenever the engine did. The
>> gasoline is safer remaining in the tank than being pumped all over the
>> road, the hot engine, and your trapped body.
>
> So tie it into the inition system or a tilt switch (some 4x4 do that one).
It is tied to the ignition system already. The problem is, the ignition
doesn't automatically turn off when you crash your car.
If you race cars, you are required to install a battery cutoff switch on
the outside in an obvious location. This is so emergency personnel
running up to save your a** can shut off the power first thing so no
spark or whatever will set things on fire.
I have a quick disconnect on my battery. Whenever I work on the car, the
first thing is always to disconnect it.

Hello Walter,
> BCS wrote:
>
>>> With the pump shut off, you have a few seconds of fuel left in the
>>> carb. With no oil pressure, your engine is going to seize anyway.
>>>
>> In a few minutes yes (and it will still run for some time after it's
>> damaged beyond repair), more than long enough off get off the road.
>> I'd put a big buzzer in and let the driver decide when it is safe to
>> shut down the engine. In some situations, I'd gladly cook the engine
>> to get to safety.
>>
> There is an override on the switch to turn the pump on anyway, but
> it's a push button you have to hold down.
>
your driving down the road talking about programing language design and suddenly
an 18 wheeler starts tail gateing and another pulls out to pass. In the middle
of that, your engine starts to splutter, something it has never done before.
What is your reaction? I'll give 10:1 that it takes you a few seconds to
recognize that the fuel has been cut, remember that there is a switch to
override it, find said switch and push it. Now add in that you didn't install
the switch (it comes standard) and you have never taking the manual out of
shrink wrap. You starting to see why it will never come standard.
>> So tie it into the inition system or a tilt switch (some 4x4 do that
>> one).
>>
> It is tied to the ignition system already. The problem is, the
> ignition doesn't automatically turn off when you crash your car.
>
Yes the ignition (as the the key) doesn't turn off but when the engine quits
running the ignition system (as in the magneto or that block of epoxy and
silicon under the hood) quits triggering the spark. Tie into that.
> If you race cars, you are required to install a battery cutoff switch
> on the outside in an obvious location. This is so emergency personnel
> running up to save your a** can shut off the power first thing so no
> spark or whatever will set things on fire.
>
> I have a quick disconnect on my battery. Whenever I work on the car,
> the first thing is always to disconnect it.
>