Infamous Software Bugs: FDIV Bug
Read the latest continuation of our Infamous Software Bugs series HERE.
This is the second post in our ‘Infamous Software Bugs’ series, created to examine some of the most well-known software blunders and the bugs that caused them. Last week we introduced you to the Mars Orbiter.
The Bug du Jour: The 1994 Intel FDIV bug.
The average computer user would never encounter this bug, as it only compromised a degree of mathematical accuracy very few users required. One of those few, a Virginia math professor, took the issue to the internet after an unsatisfactory response from Intel about his discovery. The story was eventually picked up by CNN, prompting widespread public awareness of the issue.
Intel’s FDIV Bug: Empty Cells at Empty Tables
Image from Wikimedia Commons: CPU Collection by Konstantin Lanzet
A pre-tax charge of $475 million against earnings – the total cost of processor replacements – and the reputation of Intel (although, they did get a few keychains out of it).
In 1994, it was discovered that some of the original Pentium processor models would divide floating-point numbers within a specific range with an error of 0.006%. It became known as the FDIV bug – the x86 assembly language mnemonic for Floating-point DIVision. An example shows that 4195835.0 ÷ 3145727.0 yielded 1.333739 instead of 1.333820. This was rarely encountered, though; Byte magazine estimated that only 1 in 9 billion floating point division problems (with random parameters) would produce inaccurate results.
In order to speed up the execution of floating-point calculations, Intel devised a lookup-table approach. The lookup table consisted of 1,066 table entries that were then downloaded into the chip’s programmable logic array. However, only 1,061 entries made it onto the first-generation of processors and the five lost entries were treated as empty cells. According to this article from Computerworld, when a problem involved a floating-point unit that needed to access any of those empty cells, it was given a zero response instead of a real answer. The error had passed through quality control because the zero response didn’t actually yield an answer of zero, it just caused some returns to have slight errors (typically around the tenth decimal digit).
Keep an eye out for our next and final installment of the Infamous Software Bugs series!
Olenick has a full-time staff of experienced software testers that work to ensure your software’s deployment. By using proven approaches and methodologies, you won’t be added to the list of infamous victims of poor-quality software testing. With a focus on software testing for 20+ years, we specialize in finding bugs and offering solutions.
By Nicole Gawron, Marketing and Communications Intern – Olenick & Associates, Chicago
Wikipedia’s List of Software Bugs
Top 100s Blogspot: 10 Most Expensive Software Blunders
Top 10 List: Ten Costliest Software Bugs
Gang Tan’s A Collection of Well-Known Software Failures
Computerworld: Epic Failures: 11 Infamous Software Bugs