Modern Tools for Hunting Undefined Behavior in C

AddressSanitizer (ASan)

AddressSanitizer detects memory safety issues including buffer overflows, use-after-free, use-after-return, use-after-scope, and memory leaks. It's incredibly fast, typically adding only 2x slowdown.

How to enable:

# GCC or Clang
gcc -fsanitize=address -g -O1 program.c -o program

# With additional features
gcc -fsanitize=address -fno-omit-frame-pointer -g -O1 program.c -o program

Example bug and output:

// buggy_code.c
#include <stdlib.h>

int main() {
    int *array = malloc(10 * sizeof(int));
    array[10] = 42;  // Off-by-one error!
    free(array);
    return 0;
}

ASan output:

=================================================================
==12345==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000000038
READ of size 4 at 0x602000000038 thread T0
    #0 0x4005c3 in main buggy_code.c:5
    #1 0x7f8b3c0d082f in __libc_start_main
    
0x602000000038 is located 0 bytes to the right of 40-byte region [0x602000000010,0x602000000038)
allocated by thread T0 here:
    #0 0x7f8b3c4a8d38 in malloc
    #1 0x400593 in main buggy_code.c:4

Common ASan errors and what they mean:

UndefinedBehaviorSanitizer (UBSan)

UBSan catches various forms of undefined behavior that ASan doesn't cover, including integer overflow, division by zero, null pointer dereferencing, and alignment violations. It's extremely lightweight with minimal performance impact.

How to enable:

# Basic usage
gcc -fsanitize=undefined -g program.c -o program

# With specific checks
gcc -fsanitize=undefined,float-divide-by-zero,unsigned-integer-overflow -g program.c -o program

# Print detailed diagnostics
UBSAN_OPTIONS=print_stacktrace=1 ./program

Example bug:

// ub_example.c
#include <stdio.h>
#include <limits.h>

int main() {
    int x = INT_MAX;
    int y = x + 1;  // Signed integer overflow!
    
    int *ptr = NULL;
    int value = *ptr;  // Null pointer dereference!
    
    int a = 5;
    int b = 0;
    int result = a / b;  // Division by zero!
    
    return 0;
}

UBSan output:

ub_example.c:6:15: runtime error: signed integer overflow: 2147483647 + 1 cannot be represented in type 'int'
ub_example.c:9:17: runtime error: load of null pointer of type 'int'
ub_example.c:13:18: runtime error: division by zero

Key UBSan checks:

• signed-integer-overflow - Detects signed integer overflow (undefined in C)
• unsigned-integer-overflow - Detects unsigned overflow (defined behavior, but often unintended)
• shift - Invalid shift operations (shifting by negative or >= width)
• bounds - Array bounds checking for VLA and flexible array members
• alignment - Misaligned pointer dereferencing
• null - Null pointer dereferencing
• return - Missing return statement in non-void function

ThreadSanitizer (TSan)

ThreadSanitizer detects data races in multithreaded programs. A data race occurs when two threads access the same memory location concurrently, at least one access is a write, and there's no synchronization. Data races are undefined behavior and notoriously difficult to debug.

How to enable:

# Compile with TSan
gcc -fsanitize=thread -g -O1 program.c -o program -lpthread

# Run with options
TSAN_OPTIONS="second_deadlock_stack=1" ./program

Example race condition:

// race.c
#include <pthread.h>
#include <stdio.h>

int global_counter = 0;

void *increment(void *arg) {
    for (int i = 0; i < 100000; i++) {
        global_counter++;  // Race condition!
    }
    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);
    printf("Counter: %d\n", global_counter);
    return 0;
}

TSan output:

==================
WARNING: ThreadSanitizer: data race (pid=12345)
  Write of size 4 at 0x7f8b3c000000 by thread T2:
    #0 increment race.c:8
    
  Previous write of size 4 at 0x7f8b3c000000 by thread T1:
    #0 increment race.c:8
    
  Location is global 'global_counter' of size 4 at 0x7f8b3c000000 (race+0x000000000000)
  
  Thread T2 (tid=12347, running) created by main thread at:
    #0 pthread_create
    #1 main race.c:16
    
  Thread T1 (tid=12346, running) created by main thread at:
    #0 pthread_create
    #1 main race.c:15
==================

Clang Static Analyzer

The Clang Static Analyzer performs deep analysis of C/C++ code to find bugs like null pointer dereferences, memory leaks, and undefined behavior.

How to use:

# Using scan-build
scan-build gcc -c program.c

# With make
scan-build make

# View results in browser
scan-build -o /tmp/analysis make
# Then open the HTML report

Example analysis output:

program.c:15:5: warning: Dereference of null pointer (loaded from variable 'ptr')
    *ptr = 10;
    ^~~~
program.c:23:12: warning: Potential memory leak
    return 0;
    ^~~~~~~

Cppcheck

Cppcheck is a static analysis tool that detects various types of bugs and style issues. It's particularly good at finding issues that compilers miss.

How to use:

# Basic usage
cppcheck program.c

# Enable all checks
cppcheck --enable=all program.c

# With more detail
cppcheck --enable=all --inconclusive --verbose program.c

# Generate XML report
cppcheck --enable=all --xml program.c 2> report.xml

Example output:

[program.c:12]: (error) Array 'buffer[10]' accessed at index 10, which is out of bounds.
[program.c:23]: (warning) %d in format string (no. 1) requires 'int' but the argument type is 'unsigned int'.
[program.c:45]: (style) Variable 'x' is assigned a value that is never used.
[program.c:67]: (performance) Prefer prefix ++/-- operators for non-primitive types.

GCC and Clang Warnings

Modern compilers have excellent built-in static analysis. Using the right warning flags can catch many bugs at compile time.

Recommended warning flags:

# Comprehensive warning set
gcc -Wall -Wextra -Wpedantic -Werror -Wformat=2 -Wstrict-overflow=3 \
    -Warray-bounds -Wwrite-strings -Wconversion -Wshadow \
    -Wuninitialized program.c -o program

# For maximum safety
gcc -Wall -Wextra -Werror -Wformat-security -Wstrict-overflow \
    -Warray-bounds=2 -Wformat-overflow=2 -Wformat-truncation=2 \
    -Wstringop-overflow=4 program.c -o program

Key warnings to understand:

• -Wall - Enables most commonly useful warnings
• -Wextra - Additional warnings not covered by -Wall
• -Werror - Treat warnings as errors (forces fixing them)
• -Wformat=2 - Enhanced printf/scanf format string checking
• -Wconversion - Warn about implicit type conversions that may alter values
• -Wshadow - Warn when variables shadow other variables
• -Wuninitialized - Warn about uninitialized variables

Valgrind Memcheck

How to use:

# Basic usage
valgrind ./program

# Full leak check with detailed output
valgrind --leak-check=full --show-leak-kinds=all --track-origins=yes ./program

# For better debugging info
gcc -g -O0 program.c -o program
valgrind --leak-check=full --track-origins=yes ./program

Example Valgrind output:

==12345== Invalid write of size 4
==12345==    at 0x40053E: main (program.c:12)
==12345==  Address 0x5204068 is 0 bytes after a block of size 40 alloc'd
==12345==    at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==12345==    by 0x400531: main (program.c:10)

==12345== Conditional jump or move depends on uninitialised value(s)
==12345==    at 0x400567: main (program.c:15)
==12345==  Uninitialised value was created by a heap allocation
==12345==    at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==12345==    by 0x400531: main (program.c:10)

==12345== HEAP SUMMARY:
==12345==     in use at exit: 40 bytes in 1 blocks
==12345==   total heap usage: 1 allocs, 0 frees, 40 bytes allocated
==12345== 
==12345== 40 bytes in 1 blocks are definitely lost in loss record 1 of 1
==12345==    at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==12345==    by 0x400531: main (program.c:10)

Understanding leak types:

Recent Valgrind Updates

Valgrind continues to evolve with each release. Recent versions have added:

• Better support for modern CPUs - AVX2, AVX-512 instruction support
• Improved performance - Faster execution on large programs
• Enhanced leak tracking - Better distinction between different leak types
• Better debugging information - More detailed stack traces and origin tracking
• Support for newer glibc versions - Compatibility with modern Linux distributions

Valgrind alternatives and complements:

• Helgrind - Thread error detector (use instead of Memcheck for threading issues)
• DRD - Another thread error detector with different trade-offs
• Massif - Heap profiler to analyze memory usage over time
• Cachegrind - Cache profiler for performance optimization

Off-by-One Errors

ASan will report:

heap-buffer-overflow on address 0x602000000038
0 bytes to the right of 40-byte region

What this means: You're accessing exactly one element past the end. Check loop conditions (should be < not <=) and array indexing.

Use-After-Free

ASan will report:

heap-use-after-free on address 0x602000000010
freed by thread T0 here:
    #0 free
    #1 cleanup() program.c:45
previously allocated here:
    #0 malloc
    #1 initialize() program.c:12

What this means: You freed memory and then accessed it. Look at the stack traces to see where it was freed and where you tried to use it. Common causes: dangling pointers, forgetting to set pointers to NULL after free, complex ownership issues.

Uninitialized Memory

Valgrind will report:

Conditional jump or move depends on uninitialised value(s)
Uninitialised value was created by a heap allocation

What this means: You allocated memory (malloc) but didn't initialize it before using it in a conditional. Use calloc instead of malloc, or explicitly initialize the memory.

Integer Overflow

UBSan will report:

signed integer overflow: 2147483647 + 1 cannot be represented in type 'int'

What this means: Your arithmetic exceeded the range of the integer type. Consider using larger types (long, long long), unsigned types if appropriate, or add overflow checking before the operation.

Custom Sanitizer Options

Sanitizers can be configured via environment variables:

# ASan: detect more issues
export ASAN_OPTIONS=detect_leaks=1:check_initialization_order=1:strict_init_order=1

# UBSan: print stack traces
export UBSAN_OPTIONS=print_stacktrace=1:halt_on_error=1

# TSan: more detailed output
export TSAN_OPTIONS=second_deadlock_stack=1:history_size=7

Suppression Files

For false positives or third-party library issues, you can create suppression files:

# valgrind_suppressions.txt
{
   known_openssl_leak
   Memcheck:Leak
   fun:malloc
   obj:/usr/lib/libssl.so*
}

# Use with:
valgrind --suppressions=valgrind_suppressions.txt ./program