Self-Hosted Memory Safety Tools: AddressSanitizer vs Valgrind vs ThreadSanitizer vs UBSan

Introduction

Memory bugs — buffer overflows, use-after-free, data races, and undefined behavior — are among the most difficult and dangerous categories of software defects. They can cause silent data corruption, crashes that manifest hours later on a different code path, and security vulnerabilities that persist for decades. The 2022 CWE Top 25 lists out-of-bounds writes and use-after-free as the #1 and #7 most dangerous software weaknesses.

Memory safety tools detect these bugs at runtime, before they reach production. This article compares four essential open-source sanitizers: AddressSanitizer (ASan), Valgrind/Memcheck, ThreadSanitizer (TSan), and UndefinedBehaviorSanitizer (UBSan). Each targets a different class of memory errors, and understanding when to use each is critical for shipping reliable software.

Comparison Table: Memory Safety Tools

Deep Dive: Memory Safety Tools

AddressSanitizer (ASan) — Fast Memory Error Detection

AddressSanitizer is the gold standard for detecting memory corruption bugs. It instruments every memory access at compile time, maintaining a “shadow memory” map that tracks which bytes are addressable. At ~2x slowdown, it is fast enough to run with your entire test suite.

1
2
3
4

# Compile with ASan enabled
gcc -fsanitize=address -g -o myapp myapp.c
# Or with Clang
clang -fsanitize=address -g -o myapp myapp.c

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

// Example: heap buffer overflow detected by ASan
#include <stdlib.h>

int main() {
    int* array = (int*)malloc(10 * sizeof(int));
    array[10] = 42;  // Out-of-bounds write!
    free(array);
    return 0;
}
// ASan output: "ERROR: AddressSanitizer: heap-buffer-overflow"

For CI/CD integration, add ASan to your CMake build:

1
2
3
4
5

option(ENABLE_ASAN "Enable AddressSanitizer" OFF)
if(ENABLE_ASAN)
    add_compile_options(-fsanitize=address -fno-omit-frame-pointer)
    add_link_options(-fsanitize=address)
endif()

1
2
3
4

# Build and test with ASan
cmake -B build -DENABLE_ASAN=ON
cmake --build build
./build/my_test_suite  # Any memory error halts with a detailed report

ASan’s limitations: it cannot detect uninitialized memory reads (use MemorySanitizer for that) and does not detect memory leaks by default (enable with ASAN_OPTIONS=detect_leaks=1).

Valgrind/Memcheck — No-Recompile Debugging

Valgrind is a dynamic binary instrumentation framework. Its Memcheck tool detects memory errors in already-compiled binaries — no recompilation required. This makes it invaluable for debugging third-party libraries, legacy binaries, and interpreted languages’ C extensions where you cannot easily rebuild with sanitizers.

1
2
3
4

# Install Valgrind
sudo apt-get install valgrind
# Run any binary under Memcheck
valgrind --leak-check=full --show-leak-kinds=all ./myapp

Valgrind runs your program inside a virtual CPU, tracking every memory allocation, access, and deallocation. When a bug is detected, it reports the exact source location and a detailed stack trace:

1
2
3
4
5

==12345== Invalid write of size 4
==12345==    at 0x4005A0: main (myapp.c:6)
==12345==  Address 0x5204068 is 0 bytes after a block of size 40 alloc'd
==12345==    at 0x4C2FDF0: malloc (vg_replace_malloc.c:299)
==12345==    by 0x40057F: main (myapp.c:5)

Valgrind also detects memory leaks with the --leak-check=full flag, categorizing them as “definitely lost,” “indirectly lost,” “possibly lost,” or “still reachable.”

The trade-off is speed: Valgrind runs your program ~20-30x slower than native execution. This makes it unsuitable for large test suites but perfect for targeted debugging sessions.

ThreadSanitizer (TSan) — Data Race Detection

ThreadSanitizer detects data races — the most insidious class of concurrency bugs where two threads access the same memory location without proper synchronization, and at least one access is a write. Data races can manifest only once in a million runs, making them nearly impossible to reproduce without tooling.

1
2

# Compile with TSan
clang -fsanitize=thread -g -o myapp myapp.c

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

#include <pthread.h>

int counter = 0;

void* increment(void* arg) {
    for (int i = 0; i < 1000000; i++) {
        counter++;  // Data race! No mutex protection
    }
    return NULL;
}

int main() {
    pthread_t t1, t2;
    pthread_create(&t1, NULL, increment, NULL);
    pthread_create(&t2, NULL, increment, NULL);
    pthread_join(t1, NULL);
    pthread_join(t2, NULL);
    return 0;
}
// TSan output: "WARNING: ThreadSanitizer: data race on 'counter'"

TSan tracks a vector clock for each thread, recording the happens-before relationships established by synchronization primitives (mutexes, atomics, condition variables). When two accesses to the same memory conflict in the happens-before ordering, TSan reports the race.

For Go developers, the Go runtime includes a built-in race detector:

1
2

go test -race ./...
go run -race myapp.go

UndefinedBehaviorSanitizer (UBSan) — Catching the Invisible

UndefinedBehaviorSanitizer catches operations that the C and C++ standards declare as undefined behavior — code that may appear to work but has no guaranteed semantics. This includes integer overflow, null pointer dereference, misaligned access, and type-based aliasing violations.

1
2

# Compile with UBSan
clang -fsanitize=undefined -g -o myapp myapp.c

1
2
3
4
5
6
7
8

#include <limits.h>

int main() {
    int x = INT_MAX;
    x += 1;  // Signed integer overflow — undefined behavior!
    return x;
}
// UBSan output: "runtime error: signed integer overflow: 2147483647 + 1"

UBSan’s minimal overhead (~1.2x) makes it the only sanitizer that can reasonably run in production. Some organizations run UBSan-minimal (-fsanitize=undefined-trap) in production, converting undefined behavior into immediate traps rather than silent corruption.

UBSan checks include:

• Integer overflow (-fsanitize=signed-integer-overflow)
• Division by zero (-fsanitize=integer-divide-by-zero)
• Null pointer dereference (-fsanitize=null)
• Misaligned pointer access (-fsanitize=alignment)
• Out-of-bounds variable-length array (-fsanitize=vla-bound)
• Type-based aliasing violations (-fsanitize=object-size)

Practical Testing Strategy

For comprehensive memory safety testing, combine multiple sanitizers in your CI pipeline:

1
2
3
4
5

# Run separate test passes for each sanitizer
clang -fsanitize=address -g -o test_asan myapp_test.c && ./test_asan
clang -fsanitize=thread -g -o test_tsan myapp_test.c && ./test_tsan
clang -fsanitize=undefined -g -o test_ubsan myapp_test.c && ./test_ubsan
valgrind --leak-check=full ./myapp

For large codebases, integrate sanitizers into your build system with CMake options (similar to the ASan example above) so developers can enable them per-build. Follow up with our guides on Linux debugging with GDB and LLDB, code quality scanning tools, and fuzz testing platforms.

FAQ

Can I run ASan and TSan simultaneously?

No. AddressSanitizer, ThreadSanitizer, and MemorySanitizer each instrument memory accesses differently and are mutually exclusive. You must run separate builds and test passes for each. However, you CAN combine ASan with UBSan (-fsanitize=address,undefined) and TSan with UBSan (-fsanitize=thread,undefined).

How much test coverage do I need for sanitizers to be effective?

Sanitizers only detect bugs on code paths that actually execute. The more test coverage you have, the more bugs they find. Combine sanitizer-enabled builds with fuzz testing (libFuzzer, AFL++) to explore edge cases automatically. A sanitizer-enabled fuzzer can find memory bugs in minutes that would take months of manual testing to discover.

Why does Valgrind report leaks in code that appears correct?

Valgrind’s leak detection can produce false positives for memory that is intentionally kept alive for the program’s lifetime (singletons, global caches). It categorizes these as “still reachable” — which is generally safe. Focus on “definitely lost” and “indirectly lost” categories. You can suppress known-safe allocations using Valgrind suppression files.

What is the performance cost of enabling sanitizers in my test suite?

ASan adds approximately 2x runtime overhead and 2-3x memory overhead. TSan adds 5-15x slowdown and 5-10x memory overhead. UBSan adds only ~1.2x slowdown. Valgrind/Memcheck adds 20-30x slowdown. For CI pipelines, ASan and UBSan are fast enough for full test suites. Reserve TSan for dedicated concurrency test runs and Valgrind for targeted debugging sessions.

Which sanitizer should I run first?

Start with UBSan — it has the lowest overhead and catches the most subtle bugs (undefined behavior that appears to work). Add ASan next for memory corruption detection. Finally add TSan if your program is multi-threaded. Use Valgrind as a complementary tool for leak checking and for binaries you cannot recompile.

💰 Want to test your market judgment? I use Polymarket for prediction market trading — the world’s largest prediction market platform, where you can bet on anything from election results to technology regulation timelines. Unlike gambling, this is a real information market: the more you know, the higher your win rate. I’ve made solid returns predicting technology-related events. Register with my referral link: Polymarket.com