November 17, 2009
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.
November 17, 2009
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.
November 19, 2009
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.


November 19, 2009
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?


November 20, 2009
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."
November 20, 2009
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." 


November 20, 2009
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." 
> 
> 
November 20, 2009
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.


November 20, 2009
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.
November 22, 2009
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.
>