Mars pathfinder disaster
4 points by ucirello
4 points by ucirello
This would be an easier read if it didn't have a 23-page paper as context.
Does anyone have a summary of the paper? What was the actual issue in the asynchronous code that was written in synchronous style? How did they resolve it/plan to prevent it in the future?
The paper is a survey which has this to say about Pathfinder:
- Year: 1997.
- System: Pathfinder
- Title: Software priority inversion caused images to stall
- Result: Close Call for Mission Loss
- Description: A programming error in real-time priority inheritance on mutex semaphores caused downlink of imaging to be stalled, and the computer watchdog kept resetting the computer. The error was identified and corrected using debugging features of operating system not originally planned to be used in-flight. Further documentation can be found in [23,24,25].
Not really a “disaster” compared to the other two Mars missions listed in the paper whose vehicles crashed.
[23] is a RISKS item on Pathfinder which answers your questions reasonably briefly.
https://www.cs.unc.edu/~anderson/teach/comp790/papers/mars_pathfinder_long_version.html
I don't think the particular issue is very relevant. The author seems to take issue with the very idea of CPU scheduling, and more generally with the "threads" model of concurrency. If they had an issue with, say, capitalism instead, they may have written an article about how capitalism caused the bug.
As I read it, the author seems to take issue with synchronous abstractions (so threads) and structured programming. I guess they think programming would be better if all code was interrupt handlers written in assembly.
The religion is that of deeply believing that every programming problem can be solved by applying function-based, synchronous thinking, augmented by ever-more-complicated type checking.
This is a terrible argument.
Framing this as religious zealotry is making a claim that the objects of his criticism are fundamentally irrational in their approach to software, but if this is what you really believe you should make this case honestly. Instead the author relies on innuendo and metaphor, hardly a rational counterpoint. It's lazy.
Furthermore, he makes some pretty wild, unsupported claims about what people are saying:
Religious zealots believe that this approach will remove all need for testing and remove all forms of ad-hoc design.
Who says this? Give me an example. This really doesn't sound like JPL at all. In fact I'd wager they do extensive testing. The author is full of shit.