Foundations — Common memory errors — null dereference, buffer overflow, use-after-free, double free, memory leak

Before you can understand a single memory error, you must be able to read every symbol the parent note throws at you without flinching. This page builds each one from absolutely nothing, in an order where every idea rests on the one before it. If you have never written a line of C, start here and do not skip.

0. The picture everything sits on: memory as a row of boxes

Look at the figure. The boxes are drawn as a horizontal strip. The little number under each box (0, 1, 2, 3, …) is its address — this never changes. The value inside the box is the data, and that can change any time you write to it.

Why the topic needs this: every single error — null deref, overflow, use-after-free — is about which box number you touched. If you cannot see the row of numbered boxes, none of the errors make sense. This picture is the ground floor.

1. The symbol byte and the range 0–255

Picture: one box in the strip above. Why 0–255? A byte is 8 on/off switches (bits); $2^8=256$ combinations, counted from 0, gives you 0 through 255. We won't need bit-level detail here — just know "one box = one byte = a number ≤ 255".

Why the topic needs it: when the parent note says char buf[8] it means 8 boxes in a row. When it says a string needs "12 bytes", it means 12 boxes. Buffer sizes are counted in bytes.

2. A variable — a named box

Picture: take one box in the strip, draw a name tag x hanging off it. You say x = 7; and the number 7 goes inside that box.

3. int, char — how many boxes and what shape

Picture: an int is four neighbouring boxes fenced together and treated as one value.

Why the topic needs it: sizeof(int) appears everywhere in the parent — it's literally "how many boxes does one int need?" (the answer, usually, is 4). And malloc(sizeof(int) * 1000) means "give me enough boxes for 1000 ints".

4. & — "the address of" (the box number)

Picture: point at the box named x, then read the little number printed underneath it. That number is &x.

Why the topic needs it: this is where a value lives. To make a pointer point at something, you copy its address with &.

5. Pointer and the * in a declaration

This is the star of the whole topic. Build it slowly.

In the figure: x is an ordinary box holding 7 at address 100. p is another box, and the value stored inside p is the number 100 — drawn as a red arrow reaching over to point at x. That arrow is the whole idea of a pointer.

6. *p — dereference (follow the arrow)

Picture: stand on p, read the number inside it (100), walk to box #100, open it. *p is now that box. *p = 42; writes 42 into x. printf("%d", *p); reads x's value.

Why the topic needs it: "null dereference" = following an arrow pointing at box #0. "use-after-free" = following an arrow to a box you already gave back. The word dereference is in three of the five error names.

7. NULL and address 0

Picture: a pointer with an arrow drawn as a crossed-out "🚫" instead of reaching a box — it points at the reserved, forbidden box #0.

Why the topic needs it: the operating system leaves box #0 (and its neighbourhood) unmapped — untouchable — precisely so that following a NULL arrow crashes immediately (a segfault) instead of silently corrupting data. That controlled crash is the parent's whole trick of "set p = NULL; after free so a later *p is detectable".

8. Stack vs Heap — two neighbourhoods of boxes

The figure shows one strip split in two: the stack side (auto-managed) and the heap side (the red block is a chunk you rented). Buffer overflows on the stack can smash a saved return address (a security disaster); leaks and double-frees happen on the heap.

Why the topic needs it: the five errors live in different neighbourhoods. Knowing which region a box is in tells you whether the cleanup is automatic (stack) or your job (heap). See Stack vs Heap Memory.

9. malloc and free — renting and returning heap boxes

Picture: malloc hands you a red-outlined block on the heap and a slip of paper (p) pointing at its first box. free(p) un-reserves the block — but your slip still has the number on it (now a dangling arrow). See malloc and free.

10. Arrays, [], and the string terminator \0

Picture: 8 boxes fenced together; a red marker on the box at offset i. Step past box 7 and you're trampling the neighbour's boxes → overflow.

Why the topic needs it: "hello world" is 11 letters, so it needs $11+1=12$ boxes. Into a char buf[8] (only 8 boxes) it overflows by 4 — exactly the parent's example.

11. Undefined Behaviour — why "it worked on my machine" proves nothing

Picture: a box you don't own, touched — with three arrows leaving it labelled "crash", "corrupt", "seems fine". You don't get to pick which. See Undefined Behaviour.

Why the topic needs it: this is why memory errors are so nasty. They aren't polite exceptions — a use-after-free might print the right answer today and delete a file tomorrow.

How these foundations feed the topic

Every arrow in that map is a prerequisite: you cannot understand the five errors until every node above L is solid. Related build-up notes: Pointers in C, malloc and free, Stack vs Heap Memory, Undefined Behaviour, and later Valgrind and AddressSanitizer and Buffer Overflow Exploits.

Equipment checklist

Cover the right side and answer out loud; reveal to check.