   Extremely expensive lesson on declaring variables!
  Don't know if this was ever posted before but found it while checking on errors regarding programming variables. Watch how you declare your variables or BAVOOM!Note in the linked page they have more disasters attributed to 'bad numerics'The Explosion of the Ariane 5On June 4, 1996 an unmanned Ariane 5 rocket launched by the European Space Agency exploded just forty seconds after its lift-off from Kourou, French Guiana.  The rocket was on its first voyage, after a decade of development costing $7 billion. The destroyed rocket and its cargo were valued at $500 million. A board of inquiry investigated the causes of the explosion and in two weeks issued a report. It turned out that the cause of the failure was a software error in the inertial reference system. Specifically a 64 bit floating point number relating to the horizontal velocity of the rocket with respect to the platform was converted to a 16 bit signed integer. The number was larger than 32,767, the largest integer storeable in a 16 bit signed integer, and thus the conversion failed. The following paragraphs are extracted from the report of the Inquiry Board. An interesting article on the accident and its implications by James Gleick appeared in The New York Times Magazine of 1 December 1996. The CNN article reporting the explosion, from which the above graphics were taken, is also available. On 4 June 1996, the maiden flight of the Ariane 5 launcher ended in a failure. Only about 40 seconds after initiation of the flight sequence, at an altitude of about 3700 m, the launcher veered off its flight path, broke up and exploded. The failure of the Ariane 501 was caused by the complete loss of guidance and attitude information 37 seconds after start of the main engine ignition sequence (30 seconds after lift-off). This loss of information was due to specification and design errors in the software of the inertial reference system. The internal SRI* software exception was caused during execution of a data conversion from 64-bit floating point to 16-bit signed integer value. The floating point number which was converted had a value greater than what could be represented by a 16-bit signed integer. *SRI stands for Système de Référence Inertielle or Inertial Reference System.    
  There's a few cases like this -- another classic is NASA's inability to convert between Imperial and metric units.   ;  Anyone remember the name of the radiation treatment program where an error in the software didn't allow for corrections of dosage levels?The one where if you accidentally entered the wrong number, and then reentered it, that first number was still tacked onto the real value. enter 37 when it was suppose to be 38, and the program actually thought it was 3738 or something like that.I think it was Canadian, but it was from a first year lecture many years ago, so I forget the exact details.   ;Quote:Original post by TalrothAnyone remember the name of the radiation treatment program where an error in the software didn't allow for corrections of dosage levels?Therac-25. It's a remarkably bad disaster.I don't think it worked exactly as you remember, but the trigger was certainly interface-based.   ;  hehe. I had not read the NYT magazine article yet - it seems to have a rather sneering POV.BTW, the root cause of this screwup was not mentioned. It lies in carrying over code from the previous Ariane 4. There, the specs guaranteed that the data in question fits in 16 bits; this changed in Ariane 5. Puts a new perspective on reuse, doesn't it?Also, it seems kind of funny that an exception caused this problem. If low-level routines like float->short can throw, then all other modules need to know and handle all possible causes, lest the entire system be shut down. (adding catch(...) everywhere would filter out legitimate hardware-on-fire)Seems like an argument against exceptions in the final product for anything except stuff like "airframe is tearing itself apart".   ;Quote:Original post by RavuyaQuote:Original post by TalrothAnyone remember the name of the radiation treatment program where an error in the software didn't allow for corrections of dosage levels?Therac-25. It's a remarkably bad disaster.I don't think it worked exactly as you remember, but the trigger was certainly interface-based.Whenever I read that I'm constantly baffled by the decision to remove all hardware interlocks and totally depend on the software to be correct. When I worked on a vaugely similar machine (not medical, but had to control a scary high radiation beam) it had hardware interlocks up the wazoo. Hardware engineers seem to be deeply untrusting of software (probably rightly in these kinds of situations) so how they came to remove all the hardware interlocks for the Therac machine eludes me.Ariane 5 is interesting because from what I can gather the mistake in the code wouldn't have proven fatal had the exception handler not been switched off (for "efficiency considerations" apparently). You have to wonder whether that decision was entirely justified given that they were working on something which *had* to be correct. (But then again, the hardware was probably very slow compared to anything we've got today).Interestingly both disasters came about when existing code had been moved over to a new hardware environment where (unwritten) assumptions in the code were no longer correct. Which isn't surprising as bugs introduced in that way can lie dormant for ages and the code can appear to be working perfectly fine until you hit a particularly nasty edge case.   ;Quote:Original post by OrangyTangAriane 5 is interesting because from what I can gather the mistake in the code wouldn't have proven fatal had the exception handler not been switched off (for "efficiency considerations" apparently). You have to wonder whether that decision was entirely justified given that they were working on something which *had* to be correct. (But then again, the hardware was probably very slow compared to anything we've got today).You have to keep in mind, that you can't simply plug a modern off the shelf CPU into a space vehicle, due to the radiation damage it would endure. Shielding against high energy radiation is expensive and heavy, and the faster and more integrated the circuit, the more sensitive it is to radiation. So often, more "primitive" (read: slower) components are preferred for space travel. In that light, the perceived micro-optimization might make a little more sense (although it still looks shady, I agree).Quote:Original post by OrangyTangInterestingly both disasters came about when existing code had been moved over to a new hardware environment where (unwritten) assumptions in the code were no longer correct. Which isn't surprising as bugs introduced in that way can lie dormant for ages and the code can appear to be working perfectly fine until you hit a particularly nasty edge case.I find this lack of code review even more surprising, as the Ariane-5 was originally designed for human transport.Then again, this shows that premature optimization can be fatal [wink];  For more stuff along these lines, you guys should check out the RISKS List. It's amazing how many consumer products utterly terrify me with their inadequate software.Leap years and Bush DST changes seem to be big hangups for embedded software. I don't even want to think about what the SCADA stuff running national infrastructure is patched to.   