AddressSanitizer explained: what it catches and what it costs

AddressSanitizer, or ASan, is a compiler feature that adds checks around memory accesses so bugs like buffer overflows and use-after-free stop the program with a report. Clang documents a typical slowdown of about 2x. It is a testing tool, meant for fuzzing and test runs, not for production builds.

What ASan detects

The Clang documentation lists these classes of error:

• Out-of-bounds access to heap, stack and globals
• Use-after-free
• Use-after-return
• Use-after-scope
• Double-free and invalid free
• Memory leaks (the page marks leak detection as experimental)

These are exactly the bugs that C and C++ programs hide. Without ASan, a one byte overflow may corrupt a neighbouring variable and the program keeps running. With ASan, the first bad access ends the run and tells you where.

How to turn it on

Compile and link with -fsanitize=address. The docs recommend -O1 or higher for reasonable speed and -fno-omit-frame-pointer for better stack traces:

clang++ -O1 -g -fsanitize=address -fno-omit-frame-pointer example.cc

Link with clang or clang++, not with ld directly, so the runtime comes along. For readable file and line numbers in reports, make sure llvm-symbolizer is available.

What it costs

• Time: typical slowdown of 2x.
• Memory: more real memory than a normal run, with overhead growing as allocations get smaller. The docs report up to 3x more stack memory.
• Address space: on 64-bit platforms it maps, but does not reserve, 16 or more terabytes of virtual address space, which can confuse ulimit settings.

For fuzzing that tradeoff is almost always worth it. You lose half your speed and gain the ability to see bugs that would otherwise be invisible.

What it does not do

ASan checks the code it instruments. Calls into uninstrumented libraries are only partly covered. The docs also state that static linking of executables is not supported, and that ASan is not meant for production executables because its runtime was not designed with security in mind.

It also only reports bugs the input actually triggers. That is why it works so well with a fuzzer: the fuzzer supplies many inputs, and ASan makes each bad one visible.

Tuning with ASAN_OPTIONS

Behaviour is controlled with an environment variable. Examples from the docs include detect_leaks=1 to enable leak detection on macOS, symbolize=0 to turn off online symbolization, and suppressions=file to quiet known issues in external libraries. ASAN_OPTIONS=help=1 lists every flag.

When to pick another sanitizer

ASan does not find uninitialized reads, integer overflow, or data races. Those need MemorySanitizer, UBSan and ThreadSanitizer. Our companion post compares them. In practice teams run ASan with UBSan together, and run MSan and TSan as separate builds.

Try it yourself

Open the demo to see what a container image scan reports. Then note what it cannot show: a memory bug in your own C code that only appears when a bad input arrives.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• Clang: AddressSanitizer

Last reviewed: 19 October 2026.