§14.4–14.7Common Errors … Summary

14.4 Common Errors — the gallery

Every specimen below compiles without a peep. That’s the lesson hiding under the lesson: compiling a C program is necessary for correctness, and nowhere near sufficient. (Memory management is such a reliable source of pain that newer languages hired a garbage collector garbage collector Runtime machinery in newer languages that frees unreferenced memory for you — at the cost of keeping-a-reference leaks. defined in ch. 14 — open in glossary to free unreferenced memory automatically — though, as specimen #4 shows, even that isn’t a full pardon.)

1 — Forgetting to allocate

char *src = "hello";
char *dst;              // oops! unallocated
strcpy(dst, src);       // segfault and die

strcpy expects dst to point at real memory; it points at garbage. The likely outcome is a segmentation fault segmentation fault The OS's response to an illegal memory access — "you did something wrong with memory, foolish programmer" (name explained with segmentation). defined in ch. 14 — open in glossary :

The fix: malloc(strlen(src) + 1) for dst first — or just use strdup() and make your life easier.

2 — Not allocating enough: the buffer overflow

char *src = "hello";
char *dst = (char *) malloc(strlen(src)); // too small!
strcpy(dst, src);       // "works" …

One byte short (the terminator). This buffer overflow buffer overflow Writing past an allocation's end (e.g., forgetting strlen+1); sometimes silently "works," sometimes crashes, often a security hole. defined in ch. 14 — open in glossary will often run seemingly correctly: maybe the overwritten byte belonged to nothing important, maybe malloc padded the allocation anyway. Sometimes it tramples a live variable; sometimes it crashes; and this exact species of bug is the source of many security vulnerabilities. The lesson, again: ran once ≠ correct.

3 — Forgetting to initialize

malloc hands you bytes of unknown value. Read them before writing — an uninitialized read uninitialized read Reading malloc'd memory before writing it — you get whatever unknown bytes were there. defined in ch. 14 — open in glossary — and you get whatever was there: zero if you’re lucky, something random and harmful if you’re not.

4 — Forgetting to free: the memory leak

The memory leak memory leak Forgetting to free memory; slowly fatal for long-running programs, and GC can't help while references persist. defined in ch. 14 — open in glossary — for a long-running program (a web server, a database, the OS itself) slow leakage ends in exhaustion and restart. GC languages don’t save you if you still hold a reference: no collector frees reachable memory.

5 — Freeing before you’re done: the dangling pointer

Free memory, keep using the old pointer — a dangling pointer dangling pointer Using memory after freeing it — the region may have been recycled by a later malloc. defined in ch. 14 — open in glossary . The next malloc may recycle that region; your subsequent use crashes the program or silently overwrites someone else’s valid data.

6 — Freeing repeatedly: the double free

free(x);
...
free(x);  // undefined behavior

The double free double free Freeing the same region twice — undefined behavior, often a crash. defined in ch. 14 — open in glossary — the allocator’s bookkeeping gets scrambled; crashes are the common outcome. (You met one in the wild already: chapter 10’s List_Pop race manufactured a double free with two threads.)

7 — Calling free() incorrectly

free() accepts exactly one thing: a pointer previously returned by malloc(). Pass anything else — a stack address, a pointer into the middle of an allocation — and the invalid free does bad things, reliably.

Because these errors are so common, an ecosystem of tools grew to hunt them: purify and valgrind are excellent, and once you’ve used them you’ll wonder how you survived without them (the homework makes sure you find out).

14.5 Underlying OS Support

Notice: no system calls were discussed above. That’s because malloc() and free() are library calls — the malloc library manages space inside your virtual address space, itself built on real system calls:

14.6 Other Calls

14.7 Summary

The basics of the memory-allocation API, plus its seven deadly sins. For depth: the C book (K&R) and Stevens — and for how these problems can be found and even corrected automatically, the Exterminator paper. The allocator’s own inner workings — how the library actually manages that heap — get a whole chapter soon (free-space management territory, chapter 17).