Question

I’m having a problem with free() on a struct in my C program. When I look at /proc//statm before and after the free it doesn’t seem to reduce. Am I using free() wrong in this case, or am I reading /proc//statm wrong?

Here is a test case which yields the problem:

struct mystruct {
    unsigned int arr[10000];
};

void mem() {
    char buf[30];
    snprintf(buf, 30, "/proc/%u/statm", (unsigned)getpid());
    FILE* pf = fopen(buf, "r");
    if (pf) {
        unsigned size; //       total program size
        unsigned resident;//   resident set size
        unsigned share;//      shared pages
        unsigned text;//       text (code)
        unsigned lib;//        library
        unsigned data;//       data/stack
        unsigned dt;//         dirty pages (unused in Linux 2.6)
        fscanf(pf, "%u %u %u %u %u %u", &size, &resident, &share, &text, &lib,         &data);
        printf("Memory usage: Data = %d\n", data*sysconf(_SC_PAGESIZE));
    }
    fclose(pf);
}

int main(int argc, char **argv) {
    mem();
    struct mystruct *foo = (struct mystruct *)malloc(sizeof(struct mystruct));
    mem();
    free(foo);
    mem();
}

The output is:

Memory usage: Data = 278528
Memory usage: Data = 282624
Memory usage: Data = 282624

When I would expect it to be:

Memory usage: Data = 278528
Memory usage: Data = 282624
Memory usage: Data = 278528

I’ve done a similar test with malloc’ing a (char *), then free’ing it and it works fine. Is there something special about structs?

Answer 1

Your answer is right over here on Stack Overflow, but the short version is that, for very good reasons, the memory allocator does not return memory to the host OS but keeps it (internally in your program’s data space) as a free list of some kind.

Some of the reasons the library keeps the memory are:

• Interacting with the kernel is much slower than simply executing library code
• The benefit would be small. Most programs have a steady-state or increasing memory footprint, so the time spent analyzing the heap looking for returnable memory would be completely wasted.
• Internal fragmentation makes page-aligned blocks (the only thing that could be returned to the kernel) unlikely to exist, another reason not to slow the program down looking for something that won’t be there.
• Returning a page embedded in a free block would fragment the low and high parts of the block on either side of the page.
• The few programs that do return large amounts of memory are likely to bypass malloc() and simply allocate and free pages anyway using mmap(2).