Run the suite under sanitizers, not just under the compiler
Running an existing test suite under address, thread and undefined-behaviour sanitizers surfaces a class of defect that neither the compiler nor the tests' own assertions can see, at a runtime cost low enough to run continuously.
Do this firstEvery change runs the suite before a human looks at it
The same tests, the same inputs, a different runtime. What changes is that memory and threading errors become loud instead of silent.
The cost is the thing to be honest about, because it is what decides whether this runs continuously or never: roughly a 73% slowdown and 3.4x memory for address checking, against about 20x for the previous generation of tools — the gap that moved this from an occasional audit to something a CI job can afford. Thread checking is far more expensive, 20 to 50 times slower, and is usually scoped to a subset.
Note the ceiling: a sanitizer finds defects on the paths your tests actually execute. It is a multiplier on test coverage, not a substitute for it.
The decoy
Compiler warnings at maximum. They are free and worth having and they see the program as written, not as run — the defects here are use-after-free and data races, which exist only in an execution.
Evidence
- AddressSanitizer: A Fast Address Sanity Checker — IIIOver 300 previously unknown memory-safety bugs in ten months of continuous use, with a breakdown by class, at 73% average slowdown and 3.4x memory — low enough to run in unit tests and fuzzing, against roughly 20x for the previous generation of tools.
Last reviewed 2026-08-19.