AddressSanitizer, or ASan, instruments C and C++ programs at compile time so that out of bounds access, use after free and similar memory errors stop the program with a report. LLVM documents a typical slowdown of 2x, which is cheap enough for a dedicated CI job.
What it detects
According to the Clang documentation, ASan detects out of bounds accesses to heap, stack and globals, use after free, use after return, use after scope, and double free or invalid free. Memory leak detection is listed as experimental.
Those are the bugs behind many memory safety vulnerabilities. Without a sanitizer, a one byte overflow can pass every test because nothing visibly breaks.
How to turn it on
With Clang, you compile and link with the sanitizer flag and keep frame pointers for readable traces.
clang -fsanitize=address -fno-omit-frame-pointer -g -O1 test_parser.c -o test_parser
./test_parser
When ASan finds a bug it prints the error type, the access size, and stack traces for the access and for where the memory was allocated and freed. To get file and line numbers, the docs say to make sure llvm-symbolizer is in your path or set the symbolizer path variable.
Add it to CI
Keep the sanitizer build separate from your release build. The usual pattern is one extra job.
- Build the test binaries with the sanitizer flags.
- Run the normal unit and integration tests.
- Fail the job on any sanitizer report.
- Upload the log as an artifact.
Because ASan slows execution, expect that job to take noticeably longer than the plain build. The documented typical slowdown is 2x, but measure your own, since results depend on the workload.
Pair it with fuzzing
Sanitizers and fuzzers complement each other. A fuzzer supplies unusual inputs, and a sanitizer makes the damage visible. OSS-Fuzz documentation states that its fuzzing is executed with AddressSanitizer or other sanitizers, which is why it also notes the added overhead in RAM and CPU.
Reading the first report
Fix the first error before looking at later ones, since an early memory error can cause misleading follow on reports. Look at three parts of the output: the kind of access (read or write, and its size), the stack of the bad access, and the stack of the allocation or free that made the memory invalid. The gap between those stacks usually shows the logic error, such as a pointer kept after the owner released it.
What it does not do
ASan is a testing tool, not a production defense. It only reports bugs that your tests actually trigger. Code that never runs under test is not checked. Other sanitizers cover other bug classes, such as undefined behavior and data races, and they are separate builds.
Quick check
Can I ship the sanitized binary to production?
That is not what it is designed for. Use it in test and fuzz builds, and keep production builds on your normal hardening flags.
Does it help for Rust or Go?
Safe code in those languages avoids most of these bugs by design. Sanitizers still matter for unsafe blocks and for C libraries linked in.
Sources
Last reviewed: 19 October 2026.
