Detecting Pointer Errors with Static Analysis and Sanitizers

1. Two Pillars of Automated Error Detection

In professional software development, especially in safety-critical domains, we rely on two main categories of automated tools to ensure code quality:

• Static Application Security Testing (SAST): These tools analyze your source code without executing it. They act like an extremely sophisticated compiler, building a model of your program to trace data flow and control flow, identifying potential bugs, vulnerabilities, and rule violations (like MISRA-C). You already use industry-leading examples: Coverity and Helix QAC.
• Dynamic Application Security Testing (DAST): These tools find bugs by monitoring your program as it runs. They achieve this by adding special checks ("instrumentation") to your compiled code. The most prominent example for C/C++ memory errors is AddressSanitizer (ASan).

Let's briefly formalize the concepts behind the static analysis you're already familiar with.

As the video explains, the great strength of SAST is its ability to analyze all possible code paths, even those that are difficult to trigger in testing. However, it can sometimes lack runtime context, leading to false positives. This is where dynamic analysis provides the perfect complement.

2. Deep Dive: AddressSanitizer (ASan)

AddressSanitizer is a dynamic analysis tool integrated into modern compilers like GCC and Clang. It detects memory errors with near-certain accuracy (virtually no false positives) and has a relatively low performance overhead (typically ~2x slowdown), making it practical for everyday development and testing.

What Bugs Does ASan Find?

ASan is a comprehensive tool for memory errors.

The key categories ASan detects are:

• Heap, stack, and global buffer overflows/underflows.
• Use-after-free (accessing heap memory after free()).
• Use-after-return (accessing stack memory of a function that has returned).
• Use-after-scope (accessing a stack variable whose scope has ended).
• Double-free and invalid-free.
• Memory leaks (this is technically handled by the accompanying LeakSanitizer, or LSAN, which is enabled by default with ASan).

How Does ASan Work?

Understanding ASan's mechanism is key to appreciating its power. It's built on two core concepts: shadow memory and compiler instrumentation.

In essence, the compiler instruments your code by adding checks before every memory access. This check calculates the corresponding address in shadow memory and verifies if the access is valid. If you try to read from or write to memory that the shadow map has marked as "poisoned" (e.g., a redzone, or a region that has been free'd), ASan halts the program and prints a detailed error report.

How to Use ASan

Using ASan is straightforward. You simply add a compiler and linker flag during your debug builds.

The flag is -fsanitize=address. For the best output, you should always combine it with -g to include debugging symbols.

// File: overflow_example.c
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int main() {
    // Allocate a 10-byte buffer for a short string
    char *buf = (char *)malloc(10);
    if (!buf) return 1;

    printf("Buffer allocated at: %p\n", (void*)buf);
    
    // This is fine
    strcpy(buf, "hello"); 
    printf("Buffer contains: %s\n", buf);
    
    // This will cause a heap-buffer-overflow
    printf("Attempting to write past the buffer...\n");
    buf[15] = 'X'; // Writing 6 bytes past the end of our 10-byte allocation

    printf("This line will not be reached.\n");

    free(buf);
    return 0;
}

Let's compile and run this, first without and then with ASan.

1. Compilation without ASan:
gcc -g overflow_example.c -o overflow_normal
./overflow_normal

On many systems, this program might appear to run "correctly" without crashing, silently corrupting memory. This is what makes these bugs so dangerous.

2. Compilation with ASan:
gcc -g -fsanitize=address overflow_example.c -o overflow_asan
./overflow_asan

When you run the ASan-instrumented version, the program will halt immediately upon the illegal memory access and produce a detailed report.

Interpreting the ASan Report

The output will look something like this (details may vary slightly):

=================================================================
==12345==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200000001f
WRITE of size 1 at 0x60200000001f thread T0
    #0 0x497d3a in main /path/to/overflow_example.c:20
    #1 0x7f1234567890 in __libc_start_main ../csu/libc-start.c:308
    #2 0x41928a in _start (overflow_asan+0x41928a)

0x60200000001f is located 5 bytes to the right of 10-byte region [0x602000000010,0x60200000001a)
allocated by thread T0 here:
    #0 0x4cbf8a in malloc (/path/to/overflow_asan+0x4cbf8a)
    #1 0x497c8d in main /path/to/overflow_example.c:8
    #2 0x7f1234567890 in __libc_start_main ../csu/libc-start.c:308

Let's break this down:

1. heap-buffer-overflow on address 0x...: The exact error type and the invalid memory address being accessed.
2. WRITE of size 1: The type and size of the operation.
3. #0 0x... in main /path/to/overflow_example.c:20: A stack trace showing exactly where the error occurred. In our case, line 20 is buf[15] = 'X';.
4. is located 5 bytes to the right of 10-byte region: A precise description of where the invalid access is relative to a valid memory block.
5. allocated by thread T0 here:: Another stack trace showing where the relevant block of memory (buf) was originally allocated (malloc on line 8).

This level of detail makes debugging trivial compared to chasing down the effects of silent memory corruption.

#include <stdio.h>

int* create_and_get() {
    int local_var = 100;
    printf("Address of local_var inside function: %p\n", (void*)&local_var);
    return &local_var; // Returning address of a local variable
}

int main() {
    int *dangling_ptr = create_and_get();
    printf("Address received by main: %p\n", (void*)dangling_ptr);
    
    // The stack space for local_var may be overwritten now.
    // Accessing it is undefined behavior.
    printf("Value: %d\n", *dangling_ptr); 

    return 0;
}

3. Integrating SAST and DAST into Your Workflow

For a senior engineer, the question isn't "SAST or DAST?" but "How do I use them together?".

• SAST (Coverity/QAC) is your first line of defense. It's integrated into your build server and possibly your IDE. It acts as a gatekeeper, ensuring that code with potential flaws or policy violations doesn't get merged. Its ability to scan the entire codebase makes it invaluable for maintaining baseline quality.

• DAST (AddressSanitizer) is your tool for validation during active development and testing. You use it on your local machine and in your unit/integration test environments. It validates that under real execution, your code's memory behavior is correct. It finds the subtle bugs that depend on specific runtime inputs and states, which SAST might miss.

A robust workflow looks like this:

1. Write Code: Implement your feature.
2. Static Analysis: Run Coverity/QAC (often done automatically by a CI pipeline on commit/pull request). Fix the reported high-priority issues.
3. Dynamic Analysis: Compile your code with -fsanitize=address and run your suite of unit and integration tests. The tests now do double duty: they check for functional correctness and memory safety.
4. Debug: If ASan finds an error, use its precise report to fix the bug.
5. Finalize: Once all tests pass with ASan enabled and SAST checks are clean, you can be highly confident in your code's memory safety.

Conclusion

Today, we've explored the automated tools that are indispensable for modern C development. You've seen how they move beyond the manual, defensive techniques from our last lesson into a systematic, powerful strategy for ensuring code quality.

Key Takeaways:

• SAST (Static Analysis) tools like Coverity analyze source code to find potential bugs across all code paths before execution. They are your quality gatekeepers.
• DAST (Dynamic Analysis) tools, primarily AddressSanitizer, instrument your code to find actual memory errors at runtime. They are your validation and debugging powerhouse.
• ASan works by using shadow memory to track memory validity and compiler instrumentation to check every access.
• Enabling ASan is as simple as adding the -fsanitize=address flag to your debug builds. Its reports are highly detailed and pinpoint the cause and location of memory errors.
• A professional workflow combines the strengths of both SAST and DAST to build highly reliable software.

Preview of the Next Lesson

We have now covered how to prevent pointer errors through defensive coding and how to detect them with automated tools. In our next lesson, we will shift to a higher level of abstraction: applying ownership patterns to manage pointer lifetimes in complex systems. We will discuss design-level strategies that prevent memory management bugs from being created in the first place, which is the ultimate goal for any senior developer.