Common Pointer Bugs and How to Fix Them

1. The "Big Three" Pointer Bugs

A. Null Pointer Dereference

This is the most straightforward of the pointer bugs. It occurs when you try to access the value at a NULL address.

• Cause: This typically happens in two scenarios:
  1. malloc() fails to allocate memory and returns NULL, but your code doesn't check for this and proceeds to use the pointer.
  2. A pointer is intentionally set to NULL (a good practice for "uninitialized" or "empty" pointers), but is then used before being assigned a valid memory address.
• Result: Attempting to read from or write to address NULL is forbidden by the operating system. This will cause an immediate program crash, often reported as a "segmentation fault".
• Fix: The fix is simple and was introduced in the last lesson: Always check if a pointer is NULL before you dereference it.

int *ptr = (int*)malloc(sizeof(int) * 10);

// The FIX: Always check for NULL after allocation.
if (ptr == NULL) {
    fprintf(stderr, "Memory allocation failed.\n");
    // Handle the error, maybe exit the program.
} else {
    // It's safe to use ptr now.
    *ptr = 100; // No crash!
}

// ... later, after freeing the pointer ...
free(ptr);
ptr = NULL; // Good practice!

// If you try to use it now, a check prevents a crash.
if (ptr != NULL) {
    *ptr = 200; // This code will not run.
}

While a crash is inconvenient, it's actually the best-case scenario for a bug, as it tells you exactly where the problem is. The next two bugs are far more insidious.

B. Dangling Pointers (Use-After-Free)

This is a more dangerous bug. A dangling pointer is a pointer that continues to hold the address of a memory block that has already been deallocated by free().

• Cause: Calling free(ptr) deallocates the memory, but it does not change the value of ptr itself. The pointer still "dangles," pointing to a location you no longer own.
• Result: This leads to undefined behavior. Three things might happen:
  1. It might seem to work correctly for a while, if the memory hasn't been reused yet.
  2. It might crash if the operating system has protected that memory page.
  3. Worst of all, that memory block could be re-allocated by a later malloc call for a completely different purpose. Your dangling pointer can then corrupt this new data, leading to bizarre and hard-to-diagnose bugs far from the original error.
• Fix: The established best practice is to set the pointer to NULL immediately after freeing it. Since dereferencing NULL causes a predictable crash, it turns a subtle undefined behavior bug into an easy-to-find null dereference bug.

The following video provides an excellent walkthrough of this problem and its solution.

The key takeaway is the mantra:
free(ptr);
ptr = NULL;

C. Memory Leaks

We introduced memory leaks in the last lesson as the result of forgetting to call free(). Another common way to cause a leak is by losing the only pointer to a dynamically allocated block of memory.

Here's the code pattern from the article to watch out for:

// 1. Allocate memory and assign its address to 'p'.
int* p = (int*)malloc(sizeof(int));
*p = 5; // Memory block 1 is in use.

// 2. OOPS! Reassign 'p' without freeing the old memory.
p = (int*)malloc(sizeof(int)); // Memory block 2 is allocated.
                               // The address of block 1 is now lost forever.

// Memory block 1 has been leaked.

• Fix: Be disciplined. If you need to re-assign a pointer that currently "owns" a block of memory, free the old block first or use a different pointer variable.

2. A Detective's Toolkit: Using Valgrind

How do you find these subtle memory bugs? Reviewing code helps, but it's not foolproof. In the professional world, developers use specialized tools. For C/C++ on Linux and macOS, the gold standard is Valgrind.

Valgrind is a program that runs your compiled code in a special virtual environment. It meticulously tracks every single memory allocation, deallocation, and access. It's slower than running your program normally, but its detailed reports on memory errors are invaluable.

The following video is a fantastic practical guide to using Valgrind to find the very bugs we've just discussed.

Valgrind Quick Reference:

• Compile: gcc -g -Wall my_program.c -o my_program (the -g is essential!)
• Run: valgrind ./my_program
• Key Error Messages:
  • definitely lost: A classic memory leak. You allocated memory and lost the pointer.
  • Invalid read/write ... Address ... is ... bytes inside a block of size ... free'd: A classic use-after-free (dangling pointer) bug.
  • Conditional jump or move depends on uninitialised value(s): Often a sign you're using a pointer to an invalid memory location (like a returned stack variable).
  • Invalid free(): You tried to free() the same block twice (double-free) or tried to free() a stack address.

Practical Challenge

Time to be the detective. Here is a small program with several memory bugs. Read the code, predict what the bugs are, and then think about how you would fix them. How do you think Valgrind would report these errors?

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

// This function is supposed to create and return a copy of a string.
char* duplicate_string(const char* original) {
    // BUG-ZONE 1
    char* new_string;
    new_string = (char*)malloc(strlen(original)); // A subtle bug is here
    strcpy(new_string, original);
    return new_string;
}

int main() {
    char* str1 = duplicate_string("Hello");
    printf("String 1: %s\n", str1);
    
    // BUG-ZONE 2
    free(str1);
    printf("String 1 after free: %s\n", str1);

    // BUG-ZONE 3
    char* str2 = (char*)malloc(50 * sizeof(char));
    strcpy(str2, "Initial string");
    
    str2 = duplicate_string("A completely new string");
    
    printf("String 2: %s\n", str2);

    // Final cleanup
    free(str2);
    
    return 0;
}

Conclusion

You have now confronted the three most common and dangerous pointer bugs in C. Mastering manual memory management isn't just about knowing the functions; it's about developing the discipline to avoid these pitfalls.

Key Takeaways:

• Null Dereference: A crash caused by using a NULL pointer. Fix by always checking for NULL.
• Dangling Pointer (Use-After-Free): Undefined behavior from using a pointer after its memory is free'd. Fix by setting pointers to NULL after freeing them.
• Memory Leak: Wasted memory from losing a pointer to an allocated block. Fix by ensuring every allocated block is eventually freed.
• Tools are essential: Bugs can be subtle. Tools like Valgrind are critical for systematically finding and diagnosing memory errors.

With this lesson, we conclude our deep dive into the mechanics and dangers of pointers and raw memory. You have the foundational knowledge to write C code that is both powerful and safe.

In our next lesson, we'll start building on this foundation. Instead of just managing blocks of ints or chars, we'll learn how to group related data together into custom types using structs. This is the first step toward creating more complex and organized data structures in C.