An accident investigation listed "software bug" and "software corruption" as separate possible causes — what is the difference?

They are separated because they answer different questions about the same symptom, and the distinction is sharp.

A bug means the software did exactly what it was written to do, and what it was written to do was wrong. The bits in memory are precisely the bits the developers put there. The defect is in the design or the logic.

Corruption means the software was correct and the bits changed. What executed was not what was written. The stored program, or the data it was operating on, was altered after the fact.

The reason this matters enormously in an investigation is that the two have completely different implications:

• A bug is reproducible. Same inputs, same result, every time, on every unit. You can find it by analysis, and it affects the entire fleet.
• Corruption is typically not reproducible. It happened once, on one unit, and the same software on the next aircraft is fine.

And the remedies diverge just as sharply: a bug is fixed by changing the software; corruption is fixed by restoring known-good bits and by finding out what changed them.

The engineering responses differ too, which is another reason to name them separately.

You defend against bugs with process: review, testing, static analysis, formal methods in the highest-assurance domains.

You defend against corruption with mechanisms that assume it will happen anyway: error-correcting memory, checksums over code and data, redundant computation on independent hardware, watchdogs, periodic re-verification of stored images.

Notice that none of the second list would catch a bug — a checksum over correct code that computes the wrong answer passes perfectly — and none of the first list prevents a cosmic ray. A system that needs to survive both has to do both, and knowing which one you are looking at tells you which set of defences failed.

The causes of corruption are worth listing, because they explain why it is a category rather than an anomaly.

• Memory faults. A cell that fails, or a bit that flips without failing permanently.
• Radiation. A charged particle striking a memory cell can flip a bit. At altitude this is measurably more frequent than at ground level, which is precisely why it appears in an aviation report and rarely in a discussion of web software.
• Marginal hardware — power supply excursions, timing violations, a connector that is nearly making contact.
• A different piece of software writing where it should not, which is a bug in that other software producing corruption in this one.

That last one shows the categories are not disjoint in origin, only in mechanism. What is investigated is which mechanism produced the observed behaviour, not who is ultimately at fault.

Worth adding why this vocabulary is rare outside safety-critical work: in ordinary software, corruption is usually indistinguishable from a bug because nobody is looking.

A server that misbehaves once and never again gets restarted, and the incident is closed as unexplained. Nobody checks whether the memory image differed from the binary. With error-correcting memory in most server hardware, the events are also rarer and often silently corrected.

So the distinction exists everywhere and is only investigated where the consequences justify the cost of investigating.