In the Crash Pattern series, we classify crashes by their shape — the way they present themselves in backtraces, logs, and runtime behavior. This helps us reason about failures systematically instead of chasing symptoms.
Where S1 crashes are clean, local, and deterministic, S2 crashes are the opposite. They are delayed, misleading, and often nondeterministic. They frequently appear far away from the real defect, and they often disappear when we add logging, change optimization levels, or run under a debugger. These properties make S2 one of the most frustrating categories in real‑world C++ systems.
In this article, we examine what heap corruption crashes are, how they behave, how we diagnose them, and how we fix them. Our goal is to build a reliable mental model so we can recognize S2 quickly and avoid wasting time on misleading crash locations.
What Is a "Heap Corruption Crash"?
A heap corruption crash occurs when the heap allocator discovers that its internal state has been damaged. The corruption itself happened earlier, but the allocator only detects it later when it tries to allocate, free, or manage memory.
