What does AddressSanitizer detect that valgrind does not, and vice versa?

A strong answer

A strong candidate frames What does AddressSanitizer detect that valgrind does not, and vice versa? around the exact memory layout, compiler semantics, and hardware execution model covered in Memory and Concurrency Sanitizers: ASan, UBSan, TSan, and Valgrind Massif. Compare ASan's compile-time instrumentation (fast, detects use-after-free/overflow) versus valgrind's runtime emulation (slow, no recompile).

C gives programmers direct access to memory addresses without safety bounds. This performance freedom creates critical classes of latent defects:

1. Heap and Stack Buffer Overflows: Writing 68 bytes into a 64-byte array does not immediately crash. It silently overwrites the adjacent variable or stack return pointer, corrupting application state minutes later in an unrelated function.
2. Use-After-Free (Dangling Pointers): Accessing a pointer after calling free() might succeed during local testing because the underlying virtual memory page remains mapped in the heap allocator. In production under load, the allocator reassigns that chunk to another thread, causing silent data corruption.
3. Data Races in Concurrency: Two threads access the same memory location simultaneously without synchronization, where at least one thread executes a write. These bugs are intermittent and rarely reproduce under standard interactive debuggers.
4. Transient Heap Spikes: An application processes large batches of data. It frees all allocations before exiting, showing zero memory leaks. Yet in production, the Linux Out-Of-Memory (OOM) killer terminates the process because heap usage spiked to 32 GB for two seconds midway through execution.

In a production interview, always connect the specification rule to its concrete runtime consequence: state what lives on the stack versus the heap or static storage segment, how the compiler or operating system validates alignments, lifetimes, and error codes, and what happens under adversarial or boundary inputs (such as zero-length buffers, integer overflow, concurrent mutation, or partial I/O). Backing your explanation with a small trace of register/memory state transitions immediately separates senior systems engineers from candidates who only memorized syntax.

What the interviewer is listening for

• Mastery of core invariant: Inspect memory corruption and use-after-free defects using AddressSanitizer shadow byte tracking.
• Mastery of core invariant: Catch integer overflows, null dereferences, and misalignment traps with UndefinedBehaviorSanitizer.
• Mastery of core invariant: Diagnose multi-threaded data races and missing synchronization with ThreadSanitizer vector clocks.
• Hardware and ABI awareness: Explaining how sizes, alignments, calling conventions, or kernel boundaries behave on real 64-bit targets rather than relying on implementation-defined assumptions.
• Defensive engineering: Naming the exact compiler flags (-Wall -Wextra -Werror), static analyzers, or runtime sanitizers (-fsanitize=address,undefined,thread) that verify correctness in CI.

Common mistakes

• Explaining only surface syntax without tracing the underlying memory addresses, ownership lifetime, or kernel/user-space state transitions.
• Assuming undefined behavior (such as signed overflow, uninitialized reads, strict-aliasing violations, or dangling pointers) will "just work" because it passed an unoptimized -O0 debug build.
• Ignoring return codes, partial reads/writes, alignment padding, or cleanup paths when an allocation or syscall fails midway through a function.