Skip to content

Risk Assessment

Risk Assessment

“Memory leaks on missiles don’t matter so long as the missile explodes before too much leaks. A 1995 memo: Google Groups

This sparked an interesting memory for me. I was once working with a customer who was producing on-board software for a missile. In my analysis of the code, I pointed out that they had a number of problems with storage leaks. Imagine my surprise when the customers chief software engineer said “Of course it leaks”.

He went on to point out that they had calculated the amount of memory the application would leak in the total possible flight time for the missile and then doubled that number. They added this much
additional memory to the hardware to “support” the leaks. Since the missile will explode when it hits it’s target or at the end of it’s flight, the ultimate in garbage collection is performed without programmer intervention.

 

Published inHackerterrorcybercyberPerformance

3 Comments

  1. As long as the problem is understood, reviewed and properly catered for. Especially in embedded systems with (im)proper memory management, you might not leak, but then heap fragmentation will still kill you.

    Mantra: Know and understand the system limits.

    As an example, we had a 32-bit timer in an aircraft, based on a 20 ms interval. Consequences of overflow have never been looked at, but sure thing, it would certainly be harmful. It has been reviewed and documented as a system limit: Total flight time shall not exceed 900 days (which is way beyond the required maintenance interval).

    Thus, no need to protect against it; we concluded, that the overflow won’t happen within operational limits.

    • Ralf Ertzinger

      Heap fragmentation grenades are banned by the Hague convention, though.

  2. Marcel Anacker

    Is it a missile without a destructor then?

Leave a Reply

Your email address will not be published. Required fields are marked *