6

Therac 25 is a radiation therapy machine that lead to 3 deaths and 3 injuries in 1980s. That's the worst accidents in history which are caused by software bugs. In 1993, Leveson and Turner did a thorough investigation (click the link for full version) into Therac 25 and published a paper to conclude their investigation.

I am going to give a presentation next week about these tragedies. However, I don't understand the paper's explanation on the bug. I enclose the related part of the paper as follows (ZOOM OUT to read), enter image description here

The following is some of my understanding of the code, enter image description here enter image description here enter image description here enter image description here enter image description here enter image description here

Then I got stuck!

The Magnet process is to setup all magnets and the entire process takes about 8secs. The BUG is that the PTime clears the magnet setting flag in its first execution, which is not reset later. The paper indicates, as a result, the PTime process will only check the input change for the first magnet setting because of the bug. But what I don't understand is the line in the red rectangle.

enter image description here

The line examines if the input has changed at the end of every magnet setup. Even if Ptime fails to check it, this line will still check if the change happened, and then the bug would be ineffective. I am really baffled. Since this is a very influential paper, I presume I somehow misunderstood its explanation.

alecxe
  • 11,425
  • 10
  • 49
  • 107
Tony
  • 61
  • 1
  • 2
  • 2
    Please do not link to password protected pages - the "thorough investigation" link - please provide a copy we can actually read. – AdrianHHH Sep 29 '14 at 08:20
  • For an additional reference on Therac 25: https://www.youtube.com/watch?v=izGSOsAGIVQ – Chris Kenst Nov 30 '14 at 00:14

3 Answers3

1

Here's my interpretation (caveat - I could be wrong):

Key sentence from the article:

The keyboard handler parses the mode and energy level specified by the operator and places an encoded result in another shared variable, the 2-byte mode/energy offset (MEOS) variable.

This corresponds to the code:

repeat
fetch parameter
output parameter
point to next parameter
until all parameters set

This code occurs before the Magnet routine is called, and only then. The call in the Magnet routine to check whether mode/energy has changed won't detect any changes because no input will be read in until all the magnets have been set.

Since the article indicates it takes approximately 8 seconds for all the magnets to be set, this means that new parameters could appear to be accepted depending on the user's speed (which is likely to be quite high given familiarity with the system).

Kate Paulk
  • 31,513
  • 8
  • 54
  • 108
0

I had (and still have) the same problem with this pseudocode. My thougts: Even there is no check in Ptime (in the repeat...until-loop) for editing taking place, the code must never the less work, because in the subroutine "Magnet" there is an additional check for editing (as you have marked red in the Code) AND a further check is performed in Datent directly under the call of Magnet. Thus that pseudocode is absolutely not clear!

But perhaps there is a fault in that pseudocode. If you changed the line "if mode/energy has changed then exit" in Ptime to "set mode/energy-flag" then Magnet would recognize this change and so would Datent. Then Datent would reschedule itself and all is fine!

Tim
  • 1
0

The last paragraph of the article is not clear. Does it explain how the bug was resolved or does it refer to code added before the tragedy occurred and the bug was found?

One interpretation of the code in the red box is that it is the fix to the race condition, ie the fix for the bug.

AdrianHHH
  • 1,453
  • 2
  • 12
  • 21