Memory leaks in long-running C daemons are a classic headache for system administrators and DevOps engineers. When a daemon gradually consumes all available RAM, it eventually triggers the Linux OOM (Out Of Memory) killer, leading to unexpected downtime. While modern languages offer garbage collection or ownership models, legacy systems and high-performance proxies often rely on manual memory management via malloc and free.

The Problem: A Subtle Leak in a Custom Proxy

Consider a stripped-down example of a request handler that dynamically allocates memory for a buffer but fails to free it under certain error conditions—a very common pattern in real-world systems.

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

void handle_request(const char* payload) {
    // Allocate a 1KB buffer for processing
    char* buffer = (char*)malloc(1024);
    if (!buffer) return;
    
    strncpy(buffer, payload, 1023);
    buffer[1023] = '\0';
    
    // Simulate an error condition
    if (strstr(buffer, "ERROR")) {
        // LEAK: Function returns without freeing buffer
        fprintf(stderr, "Error encountered\n");
        return; 
    }
    
    printf("Processed: %s\n", buffer);
    free(buffer);
}

int main() {
    handle_request("VALID_PAYLOAD");
    handle_request("ERROR_PAYLOAD"); // This call leaks memory
    return 0;
}

Detecting the Leak with Valgrind

Valgrind's Memcheck tool is the gold standard for tracking down these manual allocation errors. It instruments the binary, tracking every memory read, write, allocation, and deallocation.

Step-by-Step Solution

1. Compile the code with debugging symbols (-g) and without optimizations (-O0) to ensure accurate line numbers in the stack trace.

gcc -g -O0 proxy.c -o proxy

2. Run the binary through Valgrind with detailed leak checking enabled.

valgrind --leak-check=full --show-leak-kinds=all --track-origins=yes ./proxy

Analyzing the Valgrind Output

Valgrind will produce an output similar to this:

==12345== 1,024 bytes in 1 blocks are definitely lost in loss record 1 of 1
==12345==    at 0x4C31B0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==12345==    by 0x10871C: handle_request (proxy.c:7)
==12345==    by 0x108778: main (proxy.c:26)

Code Annotations & Fix

• malloc(1024): Valgrind hooks into this call, recording the allocation address and the stack trace.
• proxy.c:7: The stack trace pinpoints the exact line of allocation.
• definitely lost: Valgrind scanned the heap and registers at exit, finding no pointers to the address returned by malloc.

To fix this, we must ensure free(buffer) is called on all exit paths. In C, leveraging a goto cleanup; pattern is often preferred for complex functions, but for this simple case, a direct free suffices:

    if (strstr(buffer, "ERROR")) {
        fprintf(stderr, "Error encountered\n");
        free(buffer); // FIXED: Prevent leak
        return; 
    }

By integrating Valgrind into your CI/CD pipelines as an integration test step, you can catch these critical bugs before they manifest as midnight OOM alerts in production.