17 Software Bugs That Lingered for Years—and What Finally Fixed Them

iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more

Some of the costliest software failures began with a single wrong assumption: a unit conversion, a date format, a recovery routine, or a deployment step that nobody challenged. The 17 incidents below span spacecraft, power grids, hospitals, finance, telecommunications and personal computers. Each shows what testing missed, how the defect escaped into operations, and whether the eventual answer was new code, hardware replacement, rollback or a management change.

“Old” does not mean irrelevant. Legacy code is often reused in a faster machine, connected to a different system or operated under conditions its authors never imagined. That is why these incidents still matter to developers maintaining embedded devices, infrastructure and long-lived business applications.

At a glance: what failed and how it was corrected

Incident	Primary failure	Operational effect	Remediation category
Mariner 1 (1962)	Malformed guidance expression	Probe lost its intended trajectory; mission terminated	Software specification and verification
Hartford Civic Center roof (1978)	Structural design and calculation assumptions	Roof collapse	Engineering review and redesign
Soviet early-warning alarm (1983)	Unvalidated satellite warning	False report of U.S. missile launch	Human validation and alert logic
Therac-25 (1985–87)	Race condition, unsafe interface and weak interlocks	Radiation overdoses and deaths	Software, hardware and safety-process redesign
Morris worm (1988)	Unix protection flaw and propagation logic	About 6,000 computers blocked	Patch, segmentation and incident response
AT&T #4ESS (1990)	Faulty recovery software	Nine-hour long-distance interruption	Rollback and recovery-code correction
Patriot missile (1991)	Accumulated clock-representation error	Failed interception	Timing correction and operational controls
Pentium FDIV (1994)	Silicon lookup-table defect	Incorrect floating-point division	Chip replacement and design verification
Ariane 5 Flight 501 (1996)	Reused software overflowed under new flight conditions	Launcher broke up about 40 seconds after initiation	Range analysis, software changes and testing
Mars Climate Orbiter (1999)	Metric/customary-unit mismatch	Spacecraft lost	Interface contracts and unit validation
Y2K rollover (1999–2000)	Two-digit year representation	Potential misinterpretation of 2000 as 1900	Conversion, replacement and coordinated testing
SQL Slammer (2003)	Unpatched database vulnerability	Rapid network worm spread	Patch management and network containment
Northeast blackout (2003)	Alarm and monitoring software defects	Operators missed a cascading grid failure	Monitoring, procedures and grid controls
Stuxnet discovery (2010)	Malware altered industrial-control logic	Physical process manipulation	Segmentation, control validation and security
Knight Capital (2012)	Stale code path and inconsistent deployment	Automated trading loss of about $440 million in 45 minutes	Deployment controls and code retirement
Leap-year/date outages (2008–12)	Incorrect calendar edge-case handling	Production service interruptions	Calendar libraries, tests and monitoring
Heartbleed-class defect (disclosed 2014)	Memory-boundary error in old open-source code	Potential exposure of process memory	Library patching, key rotation and inventory

1. Mariner 1 guidance failure (1962)

The hidden assumption

A malformed expression entered the guidance software for Mariner 1, NASA’s first attempted mission to Venus. A tiny notation error changed the mathematical instruction interpreted by the onboard guidance process.

Why testing missed it

Early software verification was heavily dependent on manual review and limited test cases. The defect was syntactically plausible enough to survive the checks that existed, while no end-to-end simulation exposed the resulting guidance behavior before launch.

The operational consequence

The probe diverged from its planned course soon after launch, and the mission was terminated. A one-character-level specification mistake therefore became a launch-vehicle safety problem.

The fix and lesson

Mariner 1 established the need for independent code review, mathematical specification checks and realistic pre-launch simulation. In navigation software, a parser accepting an expression is not evidence that the expression describes the intended control law.

2. Hartford Civic Center roof collapse (1978)

The hidden assumption

The Hartford Civic Center roof failure followed structural design and calculation assumptions that did not adequately represent the completed structure. The incident is often discussed alongside software-era engineering mistakes, but the available historical summary does not establish that a standalone software bug was the sole cause.

Why testing missed it

Design calculations and reviews accepted the original model instead of challenging how load paths changed during construction and use. Ordinary checking therefore confirmed the internal consistency of assumptions rather than their suitability for the real building.

The operational consequence

The roof collapsed in 1978, turning an analytical weakness into a major public-safety event. Exact casualty details and the precise division between software, calculations and structural practice require the engineering investigation’s findings.

The fix and lesson

The durable remedy was independent engineering review, revised structural analysis and clearer responsibility for validating assumptions. Computational output must be checked against physical behavior, not treated as proof simply because the equations run.

3. Soviet early-warning false alarm (1983)

The hidden assumption

A Soviet satellite warning system reported incoming U.S. missiles when none had been launched. The system effectively assumed that a sensor-generated alert was trustworthy enough to trigger a strategic response.

Why testing missed it

Rare combinations of sensor geometry, sunlight and interpretation produced an apparently credible signal. Tests that focused on genuine launches or clean sensor data did not exercise the ambiguity between a real attack and a false positive.

The operational consequence

The alert created a narrow window in which personnel had to decide whether to escalate. Human judgment and skepticism prevented a false warning from becoming a military response.

The fix and lesson

Critical alerts need independent confirmation, confidence thresholds and procedures that let trained operators reject an implausible result. Automation should accelerate evidence gathering, not eliminate human validation where the cost of a false positive is catastrophic.

4. Therac-25 radiation overdoses (1985–1987)

The hidden assumption

Therac-25 radiation-therapy equipment allowed software timing, an unsafe user interface and inadequate hardware interlocks to interact. A rare race condition could leave the machine in a state where the displayed mode and delivered treatment diverged.

Why testing missed it

Testing treated software messages and operator actions as orderly and sequential. It did not sufficiently explore rapid edits, repeated commands or concurrent state changes, and the design removed physical safeguards that had existed in earlier machines.

The operational consequence

Patients received massive radiation overdoses; several people died. The event showed that a software race is not an abstract defect when code controls a medical beam.

The fix and lesson

Remediation required code changes, stronger hardware interlocks, safer interfaces, event logging and a formal safety process. Any system capable of causing physical harm needs defense in depth so that one timing error cannot become the final safety barrier.

5. Morris worm (1988)

The hidden assumption

Robert Morris’s worm exploited a Unix protection weakness and used multiple propagation techniques to copy itself between networked machines.

Why testing missed it

Network administrators had little centralized visibility, and connected systems were trusted more than they are today. A flaw that looked local on one host became a population-wide problem when machines accepted network requests from one another.

The operational consequence

INRIA’s historical summary estimates that about 6,000 computers were blocked or disabled. The worm’s spread also consumed processing capacity and network bandwidth, making recovery difficult while the infection was active.

The fix and lesson

Patch distribution, least-privilege services, network segmentation and incident-response coordination became essential defenses. A vulnerability’s blast radius is determined as much by connectivity and trust relationships as by the vulnerable code itself.

6. AT&T #4ESS outage (1990)

The hidden assumption

A recovery-software update for AT&T’s #4ESS telephone switches contained a fault. The recovery path assumed that handling one switch error would be isolated rather than triggering a synchronized failure elsewhere.

Why testing missed it

Normal call-processing tests exercised the feature path, not a nationwide population of switches simultaneously restarting and exchanging error messages. Recovery code often receives less testing because it runs only when something else has already gone wrong.

The operational consequence

Switches repeatedly crashed and rebooted, producing cascading failures and a nine-hour interruption of long-distance service.

The fix and lesson

Rolling back the faulty software restored service, while later changes emphasized staged deployment and dedicated failure-recovery testing. Reliability engineering must treat restart logic, alarms and fallback modes as production code, not emergency afterthoughts.

7. Patriot missile timing error (1991)

The hidden assumption

The Patriot system represented elapsed time with a finite-precision value. A very small rounding error accumulated continuously, and the system assumed that the resulting clock remained accurate enough for target tracking.

Why testing missed it

Short-duration tests showed negligible drift. The error became operationally significant only after a long period of uninterrupted operation, a condition not represented in routine test runs.

The operational consequence

The accumulated timing error contributed to a failed interception. The incident demonstrated that a value can be “close enough” per second yet materially wrong after many hours.

The fix and lesson

Corrected timing calculations, restart procedures and operational limits addressed the problem. Long-running simulations and explicit error budgets are mandatory for systems whose decisions depend on time synchronization.

8. Intel Pentium FDIV (1994)

The hidden assumption

A defect in a lookup table inside the Pentium processor returned incorrect floating-point division results for a narrow range of operands. The design assumed that the table entries were complete and accurate.

Why testing missed it

The erroneous combinations were rare, and ordinary benchmarks exercised too few of the possible divisions to expose them. Conventional software tests could not compensate for a mistake in the silicon’s arithmetic logic.

The operational consequence

WIRED reported estimates of 3–5 million defective chips in circulation and described Intel’s eventual replacement policy. It also reported a $475 million charge associated with the response; those figures are WIRED’s account, not a universal count.

The fix and lesson

Replacing processors was the practical remedy because deployed silicon could not be patched. Exhaustive design verification, formal checking of lookup tables and transparent replacement policies are the safeguards when a hardware defect produces wrong answers.

9. Ariane 5 Flight 501 (1996)

The hidden assumption

Ariane 5 reused guidance software from Ariane 4. The code assumed that an intermediate value would remain within a range that was safe on the earlier launcher, but Ariane 5’s flight profile produced a larger value.

Why testing missed it

Software reuse was treated as evidence of reliability, while the new vehicle’s acceleration and trajectory were not used to challenge every inherited assumption. The relevant overflow path was active during flight but unnecessary for the launcher’s intended guidance at that moment.

The operational consequence

The official inquiry recorded: “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 fix and lesson

The inquiry recommended new range analysis, removal or protection of nonessential computations, better system-level testing and clearer validation of reused components. Reuse transfers code, not the environmental assumptions surrounding it.

10. Mars Climate Orbiter (1999)

The hidden assumption

One guidance component supplied force data in metric units while another interpreted it as U.S. customary units. Each component could be locally correct while the interface between them was wrong.

Why testing missed it

Teams validated their own software and documentation but lacked a single enforced unit contract across the mission. Simulations did not expose the mismatch early enough to correct the trajectory.

The operational consequence

The spacecraft entered the Martian environment on the wrong path and was lost.

The fix and lesson

Explicit units in interfaces, machine-checkable types, independent navigation checks and end-to-end trajectory tests prevent this class of failure. Every numeric interface needs a declared unit, scale and sign convention.

11. Y2K date rollover (1999–2000)

The hidden assumption

Many systems stored years with two digits. As the U.S. Securities and Exchange Commission explained, the Year 2000 problem was caused by computerized systems “programmed to use a two-digit rather than four-digit number to represent the year,” allowing 2000 to be read as 1900.

Why testing missed it

For decades, the shortcut saved storage and processing space while producing correct results within the twentieth century. The defect surfaced only when a date crossed a century boundary, and dependencies were spread across applications, databases, hardware and vendors.

The operational consequence

Organizations faced risks ranging from incorrect interest calculations to scheduling and regulatory errors. Some repairs required replacing obsolete hardware or software, not merely changing a format string.

The fix and lesson

Conversion to four-digit years, inventorying embedded dates, boundary testing and coordinated remediation reduced the risk. SEC guidance emphasized verification, validation, data integrity and structured management; the lesson is to govern technical debt before its deadline arrives.

12. SQL Slammer (2003)

The hidden assumption

SQL Slammer exploited a vulnerability in database software that many organizations had not patched. Administrators implicitly assumed that an internal service was safe enough to remain exposed and unmaintained.

Why testing missed it

Security testing often examined application behavior, while patch inventories and network exposure were incomplete. A tiny worm payload could therefore reach thousands of vulnerable hosts without needing a complex user interaction.

The operational consequence

The worm spread rapidly, saturating networks and disrupting services. Exact infection totals vary by measurement and should be taken from the relevant CERT or vendor bulletin rather than inferred from anecdotal reports.

The fix and lesson

Applying the vendor patch, filtering unnecessary database traffic, segmenting networks and maintaining an accurate asset inventory are the durable controls. A vulnerability that is simple to exploit can still require disciplined operations to eliminate.

13. Northeast blackout monitoring failures (2003)

The hidden assumption

During the Northeast blackout, alarm and software-monitoring systems failed to give operators timely, reliable awareness of deteriorating grid conditions. The control room effectively assumed that a missing alarm meant a missing problem.

Why testing missed it

Monitoring defects were not tested as part of a full cascading-failure scenario. Operators therefore lacked the information needed to recognize that local events were combining into a regional emergency.

The operational consequence

A cascading grid failure spread while awareness lagged, leaving large areas without power.

The fix and lesson

Improvements required dependable alarm processing, broader situational-awareness tools, validated control-room procedures and stronger coordination among grid operators. Observability is a safety function: an unreported failure can be more dangerous than a visible one.

14. Leap-year and date-library outages (2008–2012)

The hidden assumption

Production software repeatedly mishandled leap days, leap years or calendar boundaries. Developers often encoded simplified rules instead of relying on a tested date library or documenting the calendar model being used.

Why testing missed it

Most tests use ordinary dates, so a defect appears only every few years or at a month-end boundary. Long-lived services may also carry date code written before modern libraries and automated regression suites existed.

The operational consequence

Outages and incorrect timestamps affected scheduling, billing and other time-dependent functions between 2008 and 2012. These incidents were smaller than Y2K but repeated the same long-tail pattern.

The fix and lesson

Use standards-based date libraries, test February 29 and century rules, and run synthetic time-forward tests. RFC 2550’s discussion of four-digit years and longer-horizon date risks shows why solving one rollover does not end calendar engineering.

15. Stuxnet industrial-control discovery (2010)

The hidden assumption

Stuxnet demonstrated that malicious software could alter industrial-control logic and make physical equipment behave differently from what operators saw. The hidden assumption was that trusted control instructions could be separated from cyber security concerns.

Why testing missed it

Industrial networks were often isolated from the public internet but still exposed through removable media, engineering workstations and trusted maintenance paths. Traditional IT tests also rarely modeled the physical consequences of a manipulated controller.

The operational consequence

The malware showed that software logic could influence real-world processes, turning a code compromise into equipment stress and process instability.

The fix and lesson

Defenses include strict network segmentation, signed and reviewed control logic, independent sensor checks, removable-media controls and recovery plans that can operate without compromised software. Safety instrumentation must be able to disagree with the control program.

16. Knight Capital deployment failure (2012)

The hidden assumption

A stale code path remained on one or more trading servers while a new deployment was rolled out inconsistently. The process assumed that every machine had the same executable and that an old routine could not be activated.

Why testing missed it

Pre-release tests covered the intended code path, not the combination of mixed versions and a dormant feature flag. Deployment verification did not prove that obsolete code had been removed from every server.

The operational consequence

Automated orders flooded the market, producing a reported loss of about $440 million in roughly 45 minutes. The figure comes from historical accounts and should be distinguished from any later accounting treatment.

The fix and lesson

Safe deployment requires artifact checksums, configuration parity, staged rollout, automatic rollback and a tested kill switch. Retiring code is part of change management; leaving a dormant path in production creates a future trigger.

17. Heartbleed-class library defects: a bridge to modern legacy risk (disclosed 2014)

The hidden assumption

A small memory-boundary mistake in widely deployed open-source code could expose process memory during a protocol request. The vulnerable code was older than its public disclosure, illustrating how a defect can remain latent across many releases.

Why testing missed it

Normal functional tests confirmed valid protocol exchanges but did not probe whether a peer could request bytes outside the intended buffer. The library’s broad reuse multiplied the number of products that inherited the same flaw.

The operational consequence

Potentially exposed memory could include credentials, session material or private keys, depending on the process and timing. Because this disclosure falls outside the earlier historical period, it is best read as a bridge to today’s legacy-risk problem.

The fix and lesson

Patching the library is only the first step: organizations must inventory dependencies, rotate potentially exposed secrets, invalidate sessions and verify that every service is running the corrected build. Open-source reuse needs continuous provenance and vulnerability monitoring, not a one-time approval.

What these failures have in common

• Context changes break reused code. Ariane 5 inherited software whose numeric assumptions belonged to Ariane 4; unit mismatches and stale deployment artifacts show the same pattern in different forms.
• Time is an input. Patriot drift, Y2K, leap-year defects and long-lived libraries fail only after enough elapsed time or a rare calendar boundary.
• Recovery paths deserve first-class testing. AT&T’s outage and Knight Capital’s trading incident began in restart or deployment behavior rather than the main feature path.
• Rare cases can have enormous impact. The Pentium FDIV combinations were uncommon, yet a hardware replacement campaign became necessary.
• Verification must cross organizational boundaries. Y2K remediation required inventories and coordinated testing; Mars Climate Orbiter failed at the interface between teams that each believed their own component was correct.
• Safety needs independent barriers. Therac-25 and Stuxnet show why software should not be the only line separating a bad state from physical harm.

A practical checklist for preventing the next “impossible” bug

1. Write down every assumption about units, ranges, time, hardware speed, state transitions and deployment order.
2. Test boundaries that occur rarely: long uptimes, leap days, century changes, maximum values, restarts and mixed software versions.
3. Use independent implementations or monitoring paths for safety-critical calculations and alarms.
4. Exercise recovery code under realistic fault loads, including simultaneous failures and repeated restarts.
5. Make interfaces machine-checkable where possible: units, schemas, version identifiers and allowed ranges should not live only in prose.
6. Inventory old hardware, libraries, scripts and dormant features so a vulnerability or stale path can be found before it activates.
7. Stage changes, verify the deployed artifact on every node and maintain a rollback or shutdown mechanism that has itself been tested.
8. After an incident, correct the process that allowed the assumption to survive, not just the line of code that finally failed.

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.