Therac-25, 1985–1987
Between 1985 and 1987, the Therac-25 — a radiation therapy machine built by Atomic Energy of Canada Limited — delivered massive accidental radiation overdoses to patients in at least six documented accidents, some of them fatal. The intended treatment dose could be exceeded hundreds of times over. It remains one of the most studied disasters in software engineering, and it is taught in ethics courses as well as engineering ones.
What it looked like at the time
The machine reported cryptic errors — most famously “Malfunction 54” — with no explanation of what was wrong, and operators, trained to keep treating patients, often pressed on. The overdoses didn’t happen on every machine or every day: they appeared only when operators, after long practice, entered treatment parameters quickly. That timing dependence made the bug nearly impossible to reproduce on demand and let the manufacturer initially blame equipment faults and deny the possibility of a software overdose.
Root cause
Two problems compounded. First, the software had a race condition: the operator interface and the beam-control code ran concurrently, and when certain commands were entered within a few seconds of each other, an internal counter could overflow and leave the machine set to deliver a high-power beam with the spreading target absent — the configuration that caused the overdoses. Second, the Therac-25 relied on software alone for safety, whereas its predecessors had included hardware interlocks that would have caught at least some of these failures. The unsafe code had also been carried forward from earlier machines, so its flaws were inherited rather than invented.
How it was found and fixed
Physicists and hospital staff pushed back against the manufacturer’s initial denials, and independent analysis eventually connected the accidents to the software. AECL recalled and redesigned the machines in 1987 with extensive changes to software and safety architecture. Nancy Leveson and Clark Turner’s 1993 investigation became the definitive study and required reading in software-safety and computer-ethics education.
The lasting lesson
Race conditions in concurrent code aren’t just lost search results — under the wrong circumstances they are safety failures. Safety-critical systems need defense in depth: software bugs are inevitable, so hardware interlocks, fail-safe defaults, and independent checks must exist to catch them. And a manufacturer that can’t reproduce a bug still has to take it seriously.
Practice the skill
A debugging challenge that works the same muscle:
- The Ghost Update — an async race condition to hunt down
- The Room That Won’t Leave — a debugging challenge in the same discipline