Common Dynamic Memory Errors: Leaks, Double Free, and Use-After-Free

The "Big Three" Dynamic Memory Bugs

While there are many ways to misuse memory in C, most bugs related to malloc and free fall into three categories. We'll examine them one by one.

To start, let's get a quick overview of these common errors.

Now, let's break down the first and perhaps most insidious bug: the memory leak.

1. Memory Leaks

A memory leak occurs when a program allocates memory on the heap but loses all pointers that refer to it, making it impossible to ever free() that memory. The memory remains "in use" from the operating system's perspective, but it's inaccessible to the program.

Consequences: For a short-running program, a small leak might go unnoticed. However, for long-running applications like the daemons, services, or ECU firmware you've worked on, even a tiny leak in a frequently executed code path can accumulate over time, consuming all available memory and causing the system to slow down, malloc to fail, or the entire system to crash.

There are two primary ways memory leaks happen.

Cause 1: Forgetting to free()

This is the most straightforward cause. You allocate memory and simply never deallocate it before the program terminates. The example under "Memory Leak (Forgetting to free() Memory)" in the Sanfoundry article illustrates this perfectly.

Cause 2: Reassigning a Pointer

This cause is more subtle and a common interview question. It happens when you have a pointer to a block of allocated memory, and you reassign that pointer to point somewhere else before freeing the original block.

Consider this example from the Sanfoundry article (section 5):

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

void cause_leak() {
    char *ptr = (char *)malloc(10); // Block A is allocated, ptr points to it.
    
    // ... ptr is used ...

    ptr = (char *)malloc(20); // Block B is allocated. ptr now points to Block B.
    // The only reference to Block A has been overwritten. It's now a leak.

    free(ptr); // This only frees Block B. Block A is lost forever.
}

In this scenario, the initial 10-byte block becomes orphaned and cannot be freed.

Prevention:

• Discipline: For every malloc, calloc, or realloc, ensure there's a corresponding free in all possible execution paths.
• Static Analysis: Tools like the Coverity and Helix QAC you're familiar with are excellent at detecting many types of memory leaks by analyzing the source code without running it.
• Careful Reassignment: Before reassigning a pointer that owns a memory block, always free the block first if it's no longer needed.

2. Use-After-Free (Dangling Pointers)

This bug occurs when you free() a block of memory but continue to hold a pointer to that location (now called a dangling pointer) and later try to use it to read or write data.

When you call free(ptr), you are telling the C runtime library that the memory ptr points to is no longer needed. The runtime can now give that memory to another part of your program in a subsequent malloc call. The ptr variable itself still holds the old address, but it's no longer a valid address for your use.

Let's look at a code example.

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

int main() {
    int *ptr = (int *)malloc(sizeof(int));
    *ptr = 100;
    printf("Before free, value is %d at address %p\n", *ptr, (void*)ptr);

    free(ptr); // The memory is returned to the system. ptr is now a dangling pointer.

    // UNDEFINED BEHAVIOR!
    printf("After free, value is %d\n", *ptr); 

    // What happens if we do another allocation?
    int *another_ptr = (int *)malloc(sizeof(int));
    *another_ptr = 200;
    printf("another_ptr allocated at %p\n", (void*)another_ptr);

    // The memory manager might reuse the exact same block.
    // Let's see what ptr points to now.
    printf("After new allocation, dangling ptr dereferences to: %d\n", *ptr);

    return 0;
}

Consequences (Undefined Behavior):

• It might seem to work: If the memory hasn't been reallocated yet, you might read the old value (100). This is dangerously misleading.
• Data Corruption: If the memory has been reallocated and is now used by another_ptr, writing through the dangling ptr (*ptr = 50;) would corrupt the value of *another_ptr. This is a nightmare to debug.
• Program Crash: The memory manager might have returned the page to the OS, and accessing it will cause a segmentation fault.
• Security Vulnerability: This is one of the most severe types of memory bugs from a security standpoint. An attacker could potentially gain control of the program's execution by carefully crafting inputs that cause the program to reuse the freed memory in a predictable way.

Prevention:
The single most effective defense is to invalidate the pointer immediately after freeing the memory it points to.

free(ptr);
ptr = NULL;

By setting the pointer to NULL, you change it from a "dangling" pointer to a "null" pointer. Dereferencing a NULL pointer is still a bug, but on most modern operating systems, it results in an immediate and predictable crash. This is far preferable to the silent data corruption or security exploits that a dangling pointer enables. This is an example of the "fail fast" principle.

3. Double Free

A double free error occurs when you call free() on the same memory address more than once.

Cause: This usually happens in complex code with multiple pointers to the same object or unclear ownership rules, where two different code paths attempt to clean up the same resource.

#include <stdlib.h>

int main() {
    int *p1 = (int *)malloc(sizeof(int));
    int *p2 = p1; // Both p1 and p2 point to the same memory block.

    free(p1); // Memory is freed. p1 and p2 are now dangling pointers.

    // ... some other code ...

    free(p2); // UNDEFINED BEHAVIOR: Freeing the same memory again.

    return 0;
}

Consequences (Undefined Behavior):
When you free memory, the memory allocator often writes bookkeeping information into the newly freed block to link it into a "free list." Calling free() a second time on the same block will corrupt this internal data structure. The consequences are unpredictable and severe:

• The program might crash immediately.
• The program might crash much later during a completely unrelated malloc() call.
• It could cause malloc() to return the same pointer for two different allocation requests, leading to two parts of your program stomping on each other's memory.
• Like use-after-free, this can be a critical security vulnerability.

Prevention:
The same best practice that prevents use-after-free also prevents double frees.

free(p1);
p1 = NULL;
p2 = NULL; // Invalidate all copies!

The C standard guarantees that free(NULL) is a safe operation that does nothing. Therefore, if you set your pointer to NULL after freeing, a second accidental free() call on that same pointer variable will be harmless.

Synthesis and Interview Context

Being able to list these bugs is good. Being able to compare them and discuss their prevention in the context of professional software engineering is what will set you apart in an interview.

Given your background, you can connect this directly to industry practices: this is exactly why automotive standards like MISRA C (e.g., rule 21.3) heavily restrict or outright forbid the use of malloc, calloc, realloc, and free. In a safety-critical system, the risk of these undefined behaviors is considered unacceptable. All memory is typically pre-allocated statically or on the stack to ensure deterministic behavior.

Conclusion

You now have a solid framework for identifying, explaining, and preventing the three most common and dangerous dynamic memory bugs in C.

Key Takeaways:

• Memory Leaks happen when allocated memory becomes unreachable. They cause a slow drain on system resources, which is fatal for long-running systems.
• Use-After-Free involves using a dangling pointer after the memory it points to has been deallocated. This leads to undefined behavior and is a serious security risk.
• Double Free corrupts the memory manager's internal state, leading to unpredictable crashes and potential vulnerabilities.
• The Golden Rule: The most effective preventative measure for both use-after-free and double-free errors is to set your pointer to NULL immediately after calling free().

In our next lesson, we will build on this foundation to discuss memory fragmentation, another critical consequence of dynamic allocation, and explore in more detail why standards like MISRA are so strict about it.