Hacker News Reader

Comment by boring_twenties | Hacker News Reader

I've posted about this before, but I know someone whose coworkers actually tried to defend themselves with "not leaking memory wasn't in the requirements," in a meeting with several managers, the subject of which was the memory leak.

View on HN

I don't know whether its true but there's an old story of engineers a few decades ago working on the guidance system for a missile.

The programmers didn't bother to free() any of their memory - instead they just calculated the maximum amount of RAM their program could consume while the rocket was in the air, doubled it, then installed that much ram in the rockets.

https://devblogs.microsoft.com/oldnewthing/20180228-00/?p=98...

> the ultimate in garbage collection is performed without programmer intervention.

The author owes me a new keyboard.

Thanks for the link.

Am I the only one who is terrified by reading an "amusing story" about "on-board software for a missile"? The amusement sort of requires us to completely ignore the individuals being blown to pieces.

I mean writing software for missiles kind of requires that mind set anyway

Sounds funny, but is it actually unreasonable?

Presumably, the RAM was a rounding error in the total budget.

And this move eliminated an entire class of bugs (use after free).

edit: And, you don't have to worry about memory fragmentation, or how long free() might take in the worst case.

Not at all unreasonable. You could very rightly consider any other arrangement ‘overengineered’

Eminently reasonable: dispensing with memory management (allocate/gc) for an embedded real-time missile guidance system. It may have even had static memory layout which likely further improves performance.

I'd be inclined not to use the heap at all though in that case. Just preallocate static arrays in each location.

I guess the problem is if their calculations are wrong and they are actually allocating more memory than expected.

I think a better approach (and one which NASA uses from what I've read) is to only use static memory.

When the European space agency designed the Ariane 4 rocket allocated 16 bits to some variable relating to its horizontal velocity. This variable was only used during the first minute of flight, and engineers computed that it could not possibly overflow given the launch profile Ariane 4 used. Because of this and limited processing power, engineers omitted an overflow check. This worked fine, and Ariane 4 would go on to launch succesfully 113/116 times (97%).

In 1996, Ariane 4's successor, Ariane 5, took its maiden voyage to carry the Cluster constellation into orbit, when this happened https://www.youtube.com/watch?v=gp_D8r-2hwk&t=54s

Ariane 5 used a different launch profile. The impossible was now possible and the 16 bit value overflowed. The inertial reference system failed, along with its backup (which was running the same code), causing the rocket to receive wrong data.

Sounds like more of a warning against blindly copy-pasting code across projects than anything against the Ariane 4 design.

Yes I agree.

At the same time, having added big uppercase warnings in the Ariane 4 source code and architecture docs, might have prevented this.

So, important, in safety critical code, to assume that others might blindly copy paste in bad ways -- and then try to warn them, although you might not be there any longer

This sounds distressingly similar to the Therac-25 failures. A radiotherapy machine who's software was (blindly?) copy-pasted from a previous version of the system which had hardware interlocks to prevent unsafe configurations of the radiation emitter.

The new one did not have these interlocks, instead doing everything in software. The result of this was a few people being fatally irradiated when a certain race condition was triggered.

I know the relevant xkcd, but it is always Ariane, Therac and Mars Climate Orbiter.

That's normal, as the rockets don't run an OS, run a specific , very explicitly defined, embedded program, with known states.

It's not going to malloc randomly...

In fact, it's common in real time applications to pre-allocate everything you need at the start of the program or use static memory, and never allocate afterwards.

I think the ultimate fact here is that you have a specific runtime period. Once the missile has reached its destination, you have zero memory and the runtime disappears together with the missile.

The ultimate free().

A literal destructor.

Ooh that's better.

More common than you think and a good way to do it. In a hard-real time environment where you need strong guaranties provably overshooting is a sane strategy. Freeing is not free. Missiles are extreme because they never will be reused but you can do the same at the process level. You just give the process more than it will need during its lifetime and don't bother with memory management.

Reply on news.ycombinator.com