Address Sanitizer

Address Sanitizer is a community skill for detecting memory errors in C and C++ programs, covering buffer overflows, use-after-free detection, memory leak identification, stack corruption analysis, and integration with build systems and CI pipelines for automated memory safety testing.

What Is This?

Overview

Address Sanitizer provides patterns for using ASan to find memory bugs in C and C++ codebases. It covers buffer overflow detection for heap, stack, and global memory that catches out-of-bounds reads and writes at runtime, use-after-free detection that identifies access to memory after it has been deallocated, memory leak identification that reports allocations without corresponding deallocations at program exit, stack buffer overflow detection that catches local variable overflows and stack corruption, and CI integration that runs ASan-instrumented builds in continuous integration pipelines for automated testing. The skill enables C and C++ developers to catch memory safety issues before they reach production.

Who Should Use This

This skill serves C and C++ developers debugging memory corruption and undefined behavior, security engineers auditing codebases for exploitable memory vulnerabilities, and teams integrating memory safety testing into automated CI workflows.

Why Use It?

Problems It Solves

Buffer overflows cause silent data corruption that manifests as bugs far from the original error site. Use-after-free bugs create security vulnerabilities that are difficult to reproduce under normal testing. Memory leaks accumulate gradually and only surface as performance degradation in long-running processes. Stack corruption produces crashes with misleading stack traces that obscure the root cause.

Core Highlights

Runtime detection catches buffer overflows at the exact instruction that causes the violation. Shadow memory tracks allocation state to detect use-after-free and double-free errors. Leak detector reports unreleased allocations with full allocation stack traces. Compiler instrumentation adds checks with roughly two times runtime overhead.

How to Use It?

Basic Usage

// Compile with ASan enabled
// gcc -fsanitize=address
//   -fno-omit-frame-pointer
//   -g example.c -o example

#include <stdlib.h>
#include <string.h>

// Heap buffer overflow
void heap_overflow() {
  char *buf =
    (char *)malloc(10);
  // ASan catches this:
  // writing beyond
  // allocated size
  memset(buf, 'A', 20);
  free(buf);
}

// Use-after-free
void use_after_free() {
  int *ptr =
    (int *)malloc(
      sizeof(int));
  *ptr = 42;
  free(ptr);
  // ASan catches this:
  // access after free
  int val = *ptr;
}

// Stack buffer overflow
void stack_overflow() {
  char buf[10];
  // ASan catches this:
  // stack overwrite
  memset(buf, 'B', 20);
}

int main() {
  heap_overflow();
  return 0;
}

Real-World Examples

option(ENABLE_ASAN
  "Enable AddressSanitizer"
  OFF)

if(ENABLE_ASAN)
  add_compile_options(
    -fsanitize=address
    -fno-omit-frame-pointer
    -fno-optimize-sibling-calls
  )
  add_link_options(
    -fsanitize=address
  )
endif()

Advanced Tips

Combine ASan with fuzzing tools like AFL or libFuzzer to automatically discover memory errors through generated inputs. Use ASAN_OPTIONS environment variable to configure behavior including halt_on_error for CI and suppressions for known issues. Enable detect_stack_use_after_return to catch use-after-return bugs that only manifest when stack frames are reused.

When to Use It?

Use Cases

Add ASan to a C library test suite to catch buffer overflows during unit testing. Run an ASan-instrumented build in CI to detect memory errors on every commit. Use ASan with fuzzing to discover memory corruption in parsing code.

Related Topics

Memory safety, AddressSanitizer, C/C++ debugging, fuzzing, and undefined behavior detection.

Important Notes

Requirements

GCC or Clang compiler with sanitizer support. Debug symbols enabled with the -g flag for readable stack traces. Sufficient memory overhead as ASan increases memory usage by approximately three times the baseline.

Usage Recommendations

Do: run ASan builds with your full test suite for maximum coverage of code paths. Use -fno-omit-frame-pointer for complete stack traces in error reports. Enable leak detection with detect_leaks=1 for long-running applications.

Don't: deploy ASan-instrumented binaries to production due to performance and memory overhead. Combine ASan with other sanitizers like TSan or MSan in the same build as they are incompatible. Ignore ASan reports even if the program appears to run correctly because memory errors cause undefined behavior.

Limitations

ASan cannot detect uninitialized memory reads which require MemorySanitizer instead. Runtime overhead of roughly two times makes ASan unsuitable for performance benchmarking. Some inline assembly or custom allocators may need ASan annotations for correct tracking. ASan is not supported on all platforms and embedded targets may lack runtime support.