AddressSanitizer is a compiler instrumentation that finds out-of-bounds accesses, use after free, use after return, use after scope, double free and invalid free in C and C++ programs. Clang documents a typical slowdown of 2x. It is a testing tool, not something to ship in production builds.
What it detects
The Clang documentation lists these classes:
- Out-of-bounds accesses to heap, stack and global memory
- Use after free
- Use after return and use after scope, each controlled by a flag
- Double free and invalid free
- Memory leaks, marked experimental
Turning it on
Compile and link with the sanitizer flag, keep optimization at the first level or higher, and keep frame pointers for readable stack traces:
clang -fsanitize=address -O1 -g -fno-omit-frame-pointer app.c -o app
Run your tests as normal. The first error prints a report with the access, the allocation site and, for use after free, the free site. By design it stops at the first error.
Costs and limits
- Time. Typical slowdown is 2x.
- Memory. Higher than a native run, and worse with many small allocations. Stack usage can grow by up to 3x.
- Address space. On 64 bit platforms it maps 16 TB or more of virtual address space, which can confuse ulimit settings.
- Linking. Static linking of executables is not supported.
- Not for production. The documentation says the runtime was not built with security constraints in mind.
- False positives. Container overflow checks can report false positives with partial instrumentation or small string optimization.
The OpenSSF compiler hardening guide adds a practical note: the fortify source macro is incompatible with AddressSanitizer, so leave it off in sanitizer builds.
What it will not do for you
ASan only reports bugs that your tests actually execute. A parser path that no test reaches stays unchecked. Pair it with broader inputs, such as the corpus a fuzzer builds, and with other sanitizers for undefined behavior and threads.
Reading an ASan report
A report has three parts. The first names the error type, such as a heap buffer overflow or a use after free, with the access size and address. The second is the stack of the bad access. The third is the history of the memory involved: where it was allocated and, for use after free, where it was freed.
For a use after free, the two stacks side by side usually tell the story. The free site shows who released the memory, the access site shows who still held a pointer. The fix is usually an ownership change rather than a local patch. For an overflow, check the length calculation that sized the buffer, since the faulting write is often only the symptom.
Common mistakes
- Building without debug info, which leaves reports with raw addresses.
- Running only a smoke test, so most code is never executed.
- Suppressing a report to get a green build and forgetting the suppression.
- Mixing instrumented and uninstrumented libraries and then trusting a clean run as proof about the uninstrumented parts.
Where it fits in a workflow
- Add a sanitizer build target to CI.
- Run the unit and integration tests under it on every merge.
- Keep the build separate from the shipping build, with its own flags.
- Treat a sanitizer failure as a failing test, with an owner.
Quick check
Can I ship an ASan build to customers to catch bugs in the field?
The Clang documentation says it is intended as a testing tool and its runtime was not designed with security constraints. Use production oriented options such as hardware tagging or hardened allocators instead.
Sources
Last reviewed: 19 October 2026.
