SoylentNews is people
SoylentNews
A surprisingly simple bug afflicts computers controlling planes, spacecraft and more – they get confused by big numbers. As Chris Baraniuk discovers, the glitch has led to explosions, missing space probes and more.
Tuesday, 4 June 1996 will forever be remembered as a dark day for the European Space Agency (Esa). The first flight of the crewless Ariane 5 rocket, carrying with it four very expensive scientific satellites, ended after 39 seconds in an unholy ball of smoke and fire. It's estimated that the explosion resulted in a loss of $370m (£240m).
What happened? It wasn't a mechanical failure or an act of sabotage. No, the launch ended in disaster thanks to a simple software bug. A computer getting its maths wrong – essentially getting overwhelmed by a number bigger than it expected.
How is it possible that computers get befuddled by numbers in this way? It turns out such errors are answerable for a series of disasters and mishaps in recent years, destroying rockets, making space probes go missing, and sending missiles off-target. So what are these bugs, and why do they happen?
Imagine trying to represent a value of, say, 105,350 miles on an odometer that has a maximum value of 99,999. The counter would "roll over" to 00,000 and then count up to 5,350, the remaining value. This is the same species of inaccuracy that doomed the 1996 Ariane 5 launch. More technically, it's called "integer overflow", essentially meaning that numbers are too big to be stored in a computer system, and sometimes this can cause malfunction.
Such glitches emerge with surprising frequency. It's suspected that the reason why Nasa lost contact with the Deep Impact space probe in 2013 was an integer limit being reached.
And just last week it was reported that Boeing 787 aircraft may suffer from a similar issue. The control unit managing the delivery of power to the plane's engines will automatically enter a failsafe mode – and shut down the engines – if it has been left on for over 248 days.
(Score: 3, Informative) by TheB on Thursday May 07 2015, @03:20PM
Handling integer overflow properly SHOULD BE par for the course for embedded systems design.
Too often code I review has potential overflow bugs in it. It's one of the first things I look for, and find it just about everywhere.
Even the Arduino libraries have them.
From Stepper.cpp
In this code if "this->last_step_time" + "this->step_delay" is greater than 4,294,967,295(theoretical max value of millis) it will loop forever.
Values slightly less can become stuck in the loop, but not always. It's dependent on the return of millis()
Since millis() returns unsigned long, and no program will be running for 4,294,967+ days this sounds reasonable.
However I was asked to debug a prototype that was malfunctioning. They needed 1/4 ms accuracy and modified the library to use micros() instead of millis(). The machine would randomly freeze in ~70 min intervals. New to Arduino I looked up micros() and saw "This number will overflow (go back to zero), after approximately 70 minutes." Problem found, and easily fixed.
Later I found they were having similar troubles with other machines used in production. While not using Arduinos they still would malfunction in ~50 day intervals. Multimillion dollar machines with unfixed overrun bugs. Their solution was to reset the machine every month, and were not interested in fixing the code. "It needs to be cleaned anyway."
Sad.