Posted on 02/26/2007 2:47:19 PM PST by SubGeniusX
thanks look forward to it
Control, Alt, Delete!
All the code reviews in the world won't catch something like this. Someone just forgot to list this detail as a specific requirement and something that needed testing. Happens all the time and you just have to catch it in the field.
I think it is a larger problem of America becoming more politically correct. You cannot say or do anything without someone getting p*ssed !
Sorry, your son won't be returning from his deployment, he was shot down by an ace computer programmer...
And 1.2 million of the purchase price will go to the RIAA in case any pilots decide to listen to "pirated" music while in the air. Plus, if you beam your music or data to any other Raptor, it expires in three days or three uses. So make sure you hit the target the first time and soon or your new targeting data will have a "Would you like to buy this targeting data from the Microsoft store?" placeholder instead of letting you hit the target.
Sounds like the Tacoma Narrows Bridge in WA
True, but compared to what they built it up to be, it was a non event. Wonder if the daylight savings change will screw some things up......
It's probably about data checking. A subroutine should never trust the data it gets, but still programmers make the mistake of trusting it. "The data is coming from the system itself, so why not trust it?" Big mistake. Let's say the navigation system uses local time data for its operation. Suddenly the date on the time jumps forward by one, the subroutine freaks out due to the unexpected change and crashes. What I don't understand is why the system isn't built modular so that the navigation system could just be restarted.
True story: Recently a guy was using the in-flight entertainment system of an airline, setting up a game of Tetris which allowed you to set the number of future pieces you can see. The maximum allowed value of 4 using the arrows on the screen. Then he used the seat phone, and it accepted an input of 5 from there (but nothing above 5). Looks like a programmer wrote "It's okay if it's less than or equal to 5" instead of "It's okay if it's less than five."
Not too big of a problem, except the the guy was able to use the up arrow keys to then go higher, where he was normally stopped at 4. Looks like the programmer wrote "Don't go higher if it equals 4" instead of something like "Don't go higher if it's greater than 3."
So, having bypassed the initial bounds check and unrestrained by another poorly written one, he kept hitting the up arrow until it hit 127, and next after that in a signed byte is -128 (it rolls around to negative). A negative value where a positive is expected down the line can have serious consequences, like out of bounds or data type mismatch. He hit up again, it briefly showed -128, and *poof* went the entire in-flight entertainment system. Everyone's screen went blank.
It's amazing the consequences a small bug can have.
These kind of flight essential systems go through an incredible level of code review. Including a third party review.
However, they are reviewed and tested by human beings, and human beings are ultimately fallible creatures.
This bug somehow slipped through.
They will figure out how it slipped through and rewrite their code verification procedures and make sure this mistake doesn't happen again.
They're going to be spending a lot of time convincing the Air Force and the FAA that they've fixed the flaw in the process that allowed this bug to slip through.
Thankfully this didn't result in loss of life, or even the loss of the planes.
There is a way to help that, but most people don't want to do it anymore. You write the system highly modular and mathematically prove (not just test, prove) each small module for correct operation. A program is just a big algorithm, and algorithms can be written to be provable. Then with those proofs you prove the interaction of the modules. It takes a long time, it is tedious, and it takes people very knowledgeable in higher math do to it, but it can be done.
Thank you, thank you very much. I like being splattered with the paint of a thousand insults, but I am pond scum, not just scum.;-)
SZ
Not to mention max longitude is 180, not 190.
Not exactly. A program is code+data+environment which is based on usually many algorithms. There is no way to test in a lab all permutations of data and environments. That being said, automated testing is still way undervalued. We need to do a lot more of it.
And you prove that each of those algorithms works as designed no matter what data it receives. It's not the whole way there, but it gives you a solid, proven foundation for the whole system that you can test as usual. For the in-flight entertainment example, the module should have been proven not only like "For values 1-4 as the input" (the valid values) but as "For any value X as the input."
Rumor has it that the lowest bidder had SCADS of surplus Y2K software he gave 'em a great deal on.....and some vacuum packed lentils thrown in for free....!!!
The story is in the mainstream now. So no subtrifuge needed. Plus...none of the planes they flew F-4 and 727/767, hopefully had this problem so they likely don't have experience wit it.
It doesn't matter unless you are a corporate or institutional functionary. Of course that is most of us.
LMAO! Stolt
Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.