When Code Goes Catastrophically Wrong

A tiny bug can sometimes lead to colossal consequences. After listening to too many technical podcasts in my spare time.. Let's dive into three infamous cases where a few lines of code caused chaos, destruction, and in one case, an interplanetary facepalm.

We'll also see how they could have been solved, in a very simplified way!

1. The Rocket That Went Boom: Ariane 5 Flight 501

Imagine spending a decade and $7 billion to build a rocket, only to watch it self-destruct 37 seconds after launch. That's exactly what happened to the European Space Agency's Ariane 5 rocket in 1996. The culprit? A little thing called integer overflow.

The rocket's inertial reference system tried to stuff a 64-bit floating point number into a 16-bit integer. Oops! This caused the guidance system to go haywire, resulting in an un-commanded change of trajectory. In simpler terms, the rocket thought it was drunk and decided to break dance instead of flying straight.

How could this have been prevented? By using proper exception handling and range checking. Here's a simplified example of what they should have done:

def convert_velocity(velocity_64bit):
    max_16bit = 32767  # Maximum value for a 16-bit integer
    
    try:
        velocity_16bit = int(velocity_64bit)
        if velocity_16bit > max_16bit:
            raise ValueError("Velocity out of range for 16-bit conversion")
        return velocity_16bit
    except ValueError as e:
        log_error(f"Conversion error: {e}")
        return fallback_safe_velocity()

The Ariane 5 used Ada, a language designed for embedded and real-time systems. Here's an Ada-like representation of the problem and a potential fix:

-- Original problematic code (simplified)
procedure Convert_Velocity is
   Velocity_64 : Long_Float;
   Velocity_16 : Integer_16;  -- 16-bit integer type
begin
   Velocity_64 := Get_Velocity;  -- This function returns a 64-bit float
   Velocity_16 := Integer_16(Velocity_64);  -- This conversion could cause overflow
end Convert_Velocity;

-- Improved version with error handling
procedure Convert_Velocity (Success : out Boolean) is
   Velocity_64 : Long_Float;
   Velocity_16 : Integer_16;
   Max_16 : constant := 32767;  -- Maximum value for 16-bit signed integer
begin
   Success := False;
   Velocity_64 := Get_Velocity;
   
   if Velocity_64 > Long_Float(Max_16) or Velocity_64 < Long_Float(-Max_16) then
      -- Log error and use fallback value
      Log_Error("Velocity out of range for 16-bit conversion");
      Velocity_16 := Fallback_Safe_Velocity;
   else
      Velocity_16 := Integer_16(Velocity_64);
      Success := True;
   end if;
exception
   when others =>
      Log_Error("Unexpected error in velocity conversion");
      Velocity_16 := Fallback_Safe_Velocity;
end Convert_Velocity;

Lesson learned: Always validate your inputs and handle potential overflows!

2. The $125 Million Typo: NASA's Mars Climate Orbiter

In 1999, NASA's Mars Climate Orbiter got a little too close and personal with the Red Planet, disintegrating in its atmosphere. The reason? A simple unit conversion error. One team used metric units (newtons) while another used imperial units (pound-force). It's like trying to bake a cake with a recipe that switches between cups and milliliters without telling you.

This metric mixup caused the orbiter to approach Mars at the wrong angle, turning a scientific mission into a very expensive shooting star.

How could this planetary faux pas have been prevented? By using a clear unit standard and implementing rigorous code reviews. Here's a simple example of how they could have handled unit conversions:

class Force:
    def __init__(self, value, unit):
        self.value = value
        self.unit = unit.lower()

    def to_newtons(self):
        if self.unit == 'n' or self.unit == 'newtons':
            return self.value
        elif self.unit == 'lbf' or self.unit == 'pound-force':
            return self.value * 4.448222  # Conversion factor
        else:
            raise ValueError(f"Unsupported unit: {self.unit}")

# Usage
thrust = Force(100, 'lbf')
thrust_in_newtons = thrust.to_newtons()
print(f"Thrust: {thrust_in_newtons} N")

The Mars Climate Orbiter software was written in C. Here's a C representation of the unit conversion issue and a potential solution:

#include <stdio.h>

// Original problematic code (simplified)
double apply_thrust(double force) {
    // Assume force is in pound-force, but the function expects newtons
    return calculate_trajectory(force);
}

// Improved version with explicit unit conversion
#define LBF_TO_NEWTON 4.448222

typedef enum {
    NEWTON,
    POUND_FORCE
} ForceUnit;

typedef struct {
    double value;
    ForceUnit unit;
} Force;

double force_to_newtons(Force force) {
    if (force.unit == NEWTON) {
        return force.value;
    } else if (force.unit == POUND_FORCE) {
        return force.value * LBF_TO_NEWTON;
    } else {
        fprintf(stderr, "Error: Unknown force unit\n");
        return 0.0;
    }
}

double apply_thrust(Force force) {
    double force_in_newtons = force_to_newtons(force);
    return calculate_trajectory(force_in_newtons);
}

int main() {
    Force thrust = {100.0, POUND_FORCE};
    double trajectory = apply_thrust(thrust);
    printf("Trajectory calculated with thrust: %f N\n", force_to_newtons(thrust));
    return 0;
}

Lesson learned: Standardize your units and always double-check your conversions!

3. The Bug That Fried Patients: Therac-25 Radiation Therapy Machine

In the mid-1980s, a radiation therapy machine called the Therac-25 began to malfunction in the worst way possible. Due to a race condition in the code, the machine would occasionally give patients radiation doses that were hundreds of times higher than intended. This tragic bug led to several deaths and numerous injuries.

The problem stemmed from a perfect storm of software issues: poor synchronization between concurrent processes, inadequate error checking, and a false sense of security from previous, safer models.

How could this have been prevented? By implementing thorough error checking, fail-safe mechanisms, and extensive testing. Previous models also had hardware interlocks to prevent such faults, but the Therac-25 had removed them, depending instead on software checks for safety.

Here's a simplified example of how they could have added some basic safety checks:

class RadiationMachine:
    MAX_SAFE_DOSE = 5  # Grays

    def __init__(self):
        self.current_dose = 0
        self.is_beam_on = False

    def set_dose(self, dose):
        if dose > self.MAX_SAFE_DOSE:
            raise ValueError(f"Dose exceeds safe limit of {self.MAX_SAFE_DOSE} Gy")
        self.current_dose = dose

    def activate_beam(self):
        if not self.is_beam_on and self.current_dose <= self.MAX_SAFE_DOSE:
            self.is_beam_on = True
            print("Beam activated")
        else:
            print("ERROR: Cannot activate beam")

    def emergency_shutdown(self):
        self.is_beam_on = False
        self.current_dose = 0
        print("EMERGENCY SHUTDOWN ACTIVATED")

# Usage
machine = RadiationMachine()
try:
    machine.set_dose(3)
    machine.activate_beam()
except ValueError as e:
    print(f"Error: {e}")
    machine.emergency_shutdown()

The Therac-25 used a custom assembly language. Here's a simplified pseudocode representation in a mix of assembly-like syntax and higher-level constructs to illustrate the issues and a safer approach:

; Simplified pseudocode for Therac-25 (not actual assembly)

; Original problematic code (conceptual)
SetDose:
    MOV dose, A         ; Set dose from input
    JMP ActivateBeam    ; Immediately activate beam

ActivateBeam:
    MOV 1, beam_status  ; Turn beam on
    RET

; Improved version with safety checks
SetDose:
    MOV dose, A
    CMP A, MAX_SAFE_DOSE
    JG Error            ; Jump if dose > MAX_SAFE_DOSE
    MOV A, current_dose
    RET

ActivateBeam:
    CMP beam_status, 1
    JE Error            ; Jump if beam already on
    CMP current_dose, MAX_SAFE_DOSE
    JG Error            ; Jump if dose too high
    MOV 1, beam_status
    CALL InitiateSafetyChecks
    RET

InitiateSafetyChecks:
    ; (Additional safety check procedures)
    RET

Error:
    CALL EmergencyShutdown
    RET

EmergencyShutdown:
    MOV 0, beam_status
    MOV 0, current_dose
    ; (Additional shutdown procedures)
    RET

; Main control loop
Main:
    CALL GetUserInput
    CALL SetDose
    CALL ActivateBeam
    JMP Main

Lesson learned: When lives are at stake, implement multiple layers of safety checks and fail-safe mechanisms!

Conclusion

In conclusion, these cautionary tales remind us that in the world of coding, a small oversight can lead to massive consequences. Always validate your inputs, standardize your units, implement thorough error checking, and never, ever skip those code reviews.

Nowadays it's quite standard and even expected to write tests, so make sure to create meaninful ones - no excuses!

Wikipedia is an irresistable rabbithole

As a software engineer, I’m intimately familiar with the thrill of solving complex problems, the satisfaction of optimizing code, and the endless pursuit of knowledge in a rapidly evolving field. Yet.. there’s another realm that has captured my attention and countless hours of my time (and I’m sure many are

WirekatMarkus