Notorious software bug was killing people 40 years ago — at least three people died after radiation doses that were 100x too strong from the buggy Therac-25 radiation therapy machine

Therac radiation therapy machine
(Image credit: The National Archives, catalog.archives.gov, NAID: 6361754)

Software bugs can cause a lot of anxiety, inconvenience, and leech away valuable time, but thankfully they are rarely fatal. However, back in 1985 a radiation therapy machine called the Therac-25 was only just getting started on its human killing spree. There was a bug in its software which resulted in a deadly race condition, and at least six unfortunate individuals received doses of radiation that were 100x too strong. Three people died as a result of this software bug.

When launched, Therac-25 was an attractive machine for medical institutions as it offered a revolutionary dual treatment modes in one compact machine. It could be used for electron beam therapy to address shallow tissue problems, like skin cancers. Its other operating mode was Megavolt X-ray therapy, where a high current electron beam could target deep tissue problems. You wouldn’t want to mix these modes up…

A move to software-only controls

One of the innovations delivered with Therac-25 was the move to software-only controls. Earlier machines had electromechanical hardware interlocks to prevent the kinds of radiation accidents that occurred during the operation of this device. Therac-20, for example, is said to have shared software bugs with Therac-25, but the hardware would block any unsafe operating conditions, even if the software malfunctioned.

A paper published by California Public University computer science masters student, Anne Marie Porrello, details the nature of the bug / accident across the six known cases. For this fatal bug to manifest, typically, the Therac-25 operator would mistakenly choose the wrong operating mode and quickly try and correct their error. An experienced operator could edit treatment parameters so fast that the software skipped a safety check due to a ‘race condition’ between the input handler and the radiation beam logic.

Crucially, the Therac-25 took about 8-seconds to change radiation beam mode, and fast operators could confuse the software with inputs during this time window.

Swipe to scroll horizontally
Therac-25: Radiation Accident Summary, table from Anne Marie Porrello

Date of the Accident

Location of the Accident

Extent of injuries to patient

Number of months after the first accident

June 3, 1985

Marietta, GA

Breast removal, loss of use of arm

Row 1 - Cell 3

July 26, 1985

Ontario, Canada

Total hip replacement needed

1

January 6, 1986

Yakima, WA

Minor disability and scarring

7

March 21, 1986

Tyler, TX

Death

9

April 11, 1986

Tyler, TX

Death

10

January 17,1987

Yakima, WA

Death

19

The first such accident that is documented occurred in June 1985, and the last in January 1987. Therac-25 manufacturer AECL resisted any blame attributed to their systems for months, only escalating to a thorough investigation in spring 1986. By that time, the FDA was also investigating the accidents.

In the wake of Therac-25’s killing spree, there were calls for formal verification, rigorous testing, and improved documentation for all medical software. The issues with Therac-25 has become an often-taught cautionary tale in computer science studies.

Follow Tom's Hardware on Google News, or add us as a preferred source, to get our up-to-date news, analysis, and reviews in your feeds. Make sure to click the Follow button!

Mark Tyson
News Editor

Mark Tyson is a news editor at Tom's Hardware. He enjoys covering the full breadth of PC tech; from business and semiconductor design to products approaching the edge of reason.

  • Air2004
    "In the wake of Therac-25’s killing spree"

    A little to over dramatic don't ya think?

    Sure sounds like to me that if it weren't for Operator error, the software bug wouldn't manifest.

    Now, has anyone checked to see how many people's lives have been saved by the over dose /s
    Reply
  • ttquantia
    Today, the problem of buggy and low-quality software is being escalated by the use of LLM-based software tools, which generate code without any correctness guarantees, and without any human necessarily fully understanding what the code actually does. Good luck with that! A catastrophy waiting to happen.
    Reply
  • DiamondFlyer
    It's not an exaggeration. With one short exposure, the machine literally killed, in just a few days, patients that would still have lived for months if not many years without any sort of treatment.
    The operators didn't do mistakes per se. There were some flaws in the user interface that lead the system to use older settings than the last input of the operator when the operator was too quick. It was just an unsafe, not properly designed and tested software that was used. The code was not reviewed because it was mainly based on the software from previous model that was deemed "accident free". But the previous model had hardware safeguards that created some level of protection for the patients in case errors would cause an abnormally high dose to be delivered due to an operator or software error. The new model didn't have those safeguards, was purely software operated and it's only after investigating on the problems of the new model that they realized that the older model also made those mistakes but with less harmful consequences thanks to the extra protection layers.
    Reply