Why computer programs crash

by Adam Trachtenberg

Related link: http://www.guardian.co.uk/business/story/0,3604,1039409,00.html



If the London power grid does down because they accidentally used a one amp fuse instead of a five amp fuse -- and they never discovered this over a period of two years, despite a testing program -- what does this say about the stability of computer programs, where every user action is a one amp fuse waiting to blow?

Is there any hope for complex systems?


3 Comments

anonymous2
2003-09-10 22:49:59
What?
what does this say about the stability of computer programs, where every user action is a one amp fuse waiting to blow?


Where in the world did you get the idea that *every* user action is a pontential point of utter collapse?


If you insist on making comparisons to physical systems (a dubious idea, at best), the "fuses" in some programs change their amperage under varying conditions, and at some point there may arise a mismatch.


But programs do not crash because user input is so unpredictable that each keystroke and mouse click might send the software spinning into collapse.

trachtenberga
2003-09-20 16:06:45
What?
"Every" may be hyperbolic, but you never really know how input will affect a program. For instance, there's the example of the program that worked with domestic data, but broke with international data because the capital of Ecuador -- Quito -- told the program to Quit. Or someone deciding to make your fixed size buffer overflow to corrupt the system.


Still, what I was trying to get at -- without being too literal about it -- is that there are many code pathways and it's impossible to check them all. Just as there were many electric current pathways that they weren't able to check, either.

anonymous2
2003-11-23 16:31:57
What?
I'm in agreement here. If we know the ranges and boundaries of the information to check for (if it's comming from a user or another part of the system) then we can allow for rubbish data, and put in place a system of exceptions or traps. Proper black boxing looks after process interdependance, so there should be no need for the worry about one method's actions effecting the later performance of another's.