Valgrind — detecting memory errors: Worked examples

5.1.19 · D3 · Coding › C Programming › Valgrind — detecting memory errors

Shuru karne se pehle, vocabulary ka ek picture. malloc tumhe ek block deta hai — heap bytes ki ek contiguous strip (dekho Stack vs Heap). Us strip ke har byte pe do invisible tags hain jo Memcheck maintain karta hai:

Upar wali strip dekho. Green = A-bit set (tum ise touch kar sakte ho). Hatching = V-bit undefined (byte addressable hai lekin garbage hold karta hai — tum ise touch kar sakte ho, lekin value meaningless hai jab tak tum kuch likhte nahi). Red = A-bit clear (ise touch karna ek error hai). Neeche har example bas yahi hai — "code ne kaunse coloured region ko poke kiya, aur kaise?"

The scenario matrix

Har Memcheck bug is table ka ek cell hai. Direction column geometric axis hai — "block ki kaunsi side" (sign, hamaara "quadrant" yahaan); Kind column batata hai ki teeno sawaalon mein se kaunsa fail hua.

#	Cell class	Concrete trigger	Question failed
1	Overflow — past the end (positive side)	N-element array pe `a[N]`	A-bit
2	Underflow — before the start (negative side)	`a[-1]`	A-bit
3	Use-after-free (red block ko touch karna)	`free(p)` ke baad `*p` read karna	A-bit
4	Double free (red ko do baar free karna)	`free(p); free(p);`	A-bit (freelist)
5	Uninitialised value control flow mein use karna	unwritten heap pe `if (*p)`	V-bit
6	Uninitialised value sirf copy karna (the no-error case)	`int y = x;` unused	none (V travels)
7	Zero / degenerate: `malloc(0)`, `free(NULL)`	boundary allocation sizes	none / defined
8	Leak — definitely lost	single pointer ko overwrite karna	Leak
9	Leak — indirectly lost	ek struct jo children own karta tha use lose karna	Leak
10	Leak — still reachable (the harmless case)	global pointer left unfreed	Leak (benign)
11	Real-world word problem	ek parser jo ek branch bhool jaata hai	mixed
12	Exam twist	kyun `-O2` bug ko chhupaata hai	tooling

Do "no-error" cells (6, 7, 10-benign) utni hi zaruri hain jitni red wali: tumhe pata hona chahiye ki Valgrind jaanboojhkar kab silent rehta hai, warna tum ghosts ke peeche bhaagoge.

Example 1 — Overflow past the end (Cell 1, positive side)

Forecast: aage padhne se pehle andaaza lagao ki bad write kis byte offset pe padti hai.

Block ke bytes count karo. 5 * sizeof(int) jab sizeof(int) = 4 ho toh $5 \times 4 = 20$ bytes milte hain, offsets $0$ se $19$ tak. Yeh step kyun? A-bits exactly $[0, 20)$ pe set hain — us side pe baaki sab red hai.
a[5] locate karo. Index $5$ matlab byte offset $5 \times 4 = 20$ , 4 bytes likhna: offsets $20, 21, 22, 23$ . Yeh step kyun? Offset $20$ block ke baad ka pehla byte hai — positive side pe pehla red byte.
A-bits check karo. $A [20] = 0 \Rightarrow$ Invalid write of size 4. Yeh step kyun? Parent ka rule: access OK $⟺$ har touched byte accessible ho. Byte 20 nahi hai.

Valgrind print karta hai: Address 0x... is 0 bytes after a block of size 20 alloc'd.

Verify: offset $= 5 \times 4 = 20$ ; block size $= 5 \times 4 = 20$ ; gap $= 20 - 20 = 0$ bytes after. ✓

Example 2 — Underflow before the start (Cell 2, negative side)

Forecast: a[-1] kaunsa byte likhta hai, aur kya yeh pehle hai ya baad mein?

Offset compute karo. Index $- 1$ → byte offset $- 1 \times 4 = - 4$ , yaani offsets $- 4, - 3, - 2, - 1$ . Yeh step kyun? Negative index backwards chalta hai — Example 1 ka mirror image. Bahut se students is poore quadrant ko bhool jaate hain.
A-bits check karo. Offset $- 4.. - 1$ pe bytes block se pehle hain, A-bit $= 0$ → Invalid write of size 4. Yeh step kyun? Same rule, opposite direction; Memcheck dono edges guard karta hai (figure dekho).

Valgrind print karta hai: Address 0x... is 4 bytes before a block of size 20 alloc'd.

Verify: offset $= - 1 \times 4 = - 4$ ; magnitude $= ∣ - 4∣ = 4$ bytes before the block. ✓

Example 3 — Use-after-free (Cell 3, touching red)

Forecast: tumne pehle ek defined value likhi thi — kya yeh read ko safe banata hai?

free(p) ke baad. Parent ka rule: free $A [block] = 0$ set karta hai aur block ko quarantine karta hai taaki reuse na ho. Yeh step kyun? Quarantine A-bit ko 0 pe rakhta hai itni der tak ki hum pakde jaayein; iske bina fresh malloc bytes ko green recolour kar sakta tha aur bug ko chhupaata.
*p read karo. Byte offset 0 ab A-bit $= 0$ rakhta hai → Invalid read of size 4. Yeh step kyun? Yeh ek A-bit error hai — "yeh tumhara touch karne ka haq nahi" — chahe value ek baar defined thi. Defined-ness irrelevant ho jaati hai jab touch karna hi forbidden ho.

Valgrind print karta hai: Invalid read of size 4 ... Address 0x... is 0 bytes inside a block of size 4 free'd.

Verify: block size $= 4$ bytes; offset $0$ pe read, jo ki freed block ke andar $0$ bytes hai. ✓

Example 4 — Double free (Cell 4)

Forecast: pehla free successful tha — toh doosra kyun fail hota hai?

Pehla free(p). Block quarantine freelist pe chala jaata hai; A-bits $= 0$ . Yeh step kyun? Memcheck ab yaad rakhta hai ki yeh block dead hai.
Doosra free(p). Valgrind check karta hai: kya yeh pointer kisi currently allocated block ki taraf hai? Nahi — yeh freelist pe hai → Invalid free() / delete / delete[]. Yeh step kyun? Already-freed pointer ko free karna real allocator ki bookkeeping corrupt karta hai (dekho malloc and free) — classic Undefined Behaviour in C.

Valgrind print karta hai: Invalid free() ... Address 0x... is 0 bytes inside a block of size 4 free'd.

Verify (logical): do frees ke baad allocated blocks $= 1 - 1 - 1 = - 1 < 0$ , impossible → doosra free invalid hai. ✓

Example 5 — Uninitialised value in control flow (Cell 5, V-bit)

Forecast: byte addressable hai — toh crime kahan hai?

A-bit theek hai. Tumne malloc kiya, toh $A = 1$ $[0, 4)$ ke upar — read khud allowed hai. Yeh step kyun? A-bit report rule out ho jaata hai; addressability ke baare mein silent rahega.
V-bit undefined hai. Tumne *p kabhi nahi likha, toh uske V-bits "garbage" kehte hain. Yeh step kyun? Comparison *p == 0 ek aisa result produce karta hai jiska truth garbage pe depend karta hai.
if us result ko control flow ke liye use karta hai. Ab Memcheck fire karta hai: Conditional jump or move depends on uninitialised value(s). Yeh step kyun? Memcheck undefined values ko silently travel karne deta hai; woh sirf us waqt complain karta hai jab garbage actually program ke kaam ko badalta hai — ek branch ya syscall.

Verify (logical): branch outcome undefined bits ka function hai ⇒ program behaviour non-deterministic hai ⇒ exactly wahi condition jo Memcheck flag karta hai. ✓

Example 6 — Uninitialised value merely copied (Cell 6, the NO-error case)

Worked example Statement

int *p = malloc(sizeof(int)); // undefined
int y = *p;                   // garbage copy karo
free(p);                      // y kabhi use nahi

Kya Valgrind complain karta hai?

Forecast: humne undefined memory read ki — surely yeh bug hai?

int y = *p; undefined V-bits ko y mein copy karta hai. Koi error nahi. Yeh step kyun? Garbage copy karna Memcheck ke model mein legal hai — V-bits saath saath chale jaate hain value ke andar y mein.
y kabhi branch, index, ya output mein use nahi hota. Toh garbage kabhi behaviour influence nahi karta → silent. Yeh step kyun? Yeh deliberate design hai: har copy ko flag karna tumhe false positives mein dubaa deta.

Verify (logical): Memcheck errors yahaan $= 0$ (koi branch/output undefined bits consume nahi karta). ✓

Example 7 — Zero and degenerate inputs (Cell 7)

Forecast: kya tum kuch bhi nahi allocate kar sakte? Kya tum kuch bhi nahi free kar sakte?

malloc(0) ya toh NULL return karta hai ya ek unique pointer jo tum free ko pass kar sakte ho lekin dereference nahi kar sakte (0 addressable bytes). Yeh step kyun? Block ka size 0 hai, toh koi bhi *q hota "0 bytes after a block of size 0" — lekin hum dereference nahi karte, toh koi error nahi.
free(q) valid hai chahe q woh zero-size block ho ya NULL. Yeh step kyun? C standard ise well-defined banata hai; Memcheck bhi agree karta hai.
free(NULL) explicitly standard ke anusaar no-op hai. Yeh step kyun? Yeh degenerate limit hai — free operation ka "zero input" — aur yeh silent hai, error nahi.

Verify (logical): errors $= 0$ ; dono frees standard-defined no-ops / valid hain. ✓

Example 8 — Definitely lost (Cell 8)

Forecast: kitne blocks alive hain? Kitne pointers unhe reach karne ke liye survive karte hain?

buf = malloc(200) ke baad. 100-byte block ka address kahin nahi — usse hold karne wala single variable overwrite ho gaya. Yeh step kyun? Exit-time mark-and-sweep live pointers se shuru hota hai; agar koi block ke andar point nahi karta, toh unreachable hai.
Classify karo. Unreachable aur koi interior pointer nahi → definitely lost: 100 bytes in 1 block. Yeh step kyun? Parent ke leak-rule tree se exactly match karta hai.
200 block free ho jaata hai → theek hai.

Verify: leaked bytes $= \sum unreachable sizes = 100$ ; cleanly freed $= 200$ . ✓

Example 9 — Indirectly lost (Cell 9)

Worked example Statement

struct Node { struct Node *next; };
struct Node *head = malloc(sizeof *head);   // block P
head->next = malloc(sizeof *head);          // block C, P ke through reach hota hai
head = NULL;                                // P drop karo

sizeof(struct Node) = 8 ke saath, dono blocks classify karo.

Forecast: head chala gaya — lekin C ka pointer P ke andar abhi bhi hai. Kya woh C ko bachata hai?

P drop karo. head = NULL set karne se block P unreachable ho jaata hai → definitely lost, 8 bytes. Yeh step kyun? Koi live variable P ki taraf point nahi karta.
C ke baare mein kya? C ka ek hi pointer P ke andar rehta hai — lekin P khud lost hai. Toh C sirf ek lost block ke through reachable hai → indirectly lost, 8 bytes. Yeh step kyun? Yahi "indirectly lost" category ka poora point hai: tumne root khoya, aur jo kuch uska tha sab saath gir gaya.

Verify: definitely lost $= 8$ ; indirectly lost $= 8$ ; total unreachable $= 8 + 8 = 16$ bytes. ✓

Example 10 — Still reachable, the benign case (Cell 10)

Forecast: humne kabhi free(pool) nahi kiya — kya yeh "definitely lost" bug hai?

Exit pe, pool abhi bhi address hold karta hai. Ek live (global) pointer block ke andar point karta hai. Yeh step kyun? Global se reachability count hoti hai — block findable hai.
Still reachable classify karo: 50 bytes. "Definitely lost" nahi. Yeh step kyun? OS process exit pe ise reclaim kar leta hai; yeh harmless leak category hai jise parent ne over-prioritise na karne ki warning di thi.

Verify: still-reachable bytes $= 50$ ; definitely-lost $= 0$ . ✓

Example 11 — Real-world word problem (Cell 11)

Forecast: kaunsi lines lost blocks produce karti hain?

Valid lines (7). Pointer array mein store hota hai → exit pe reachable → definitely lost nahi. Yeh step kyun? Array root unhe findable rakhta hai.
Blank lines (3). Buffer allocate hota hai, next iteration pe pointer overwrite hota hai, kabhi store nahi hota, kabhi free nahi hota → har ek unreachable. Yeh step kyun? continue storage aur free dono skip karta hai, block ko orphan kar deta hai.
Total. $3 \times 64 = 192$ bytes definitely lost 3 blocks mein. Yeh step kyun? Har blank line ek orphaned 64-byte block contribute karti hai.

Verify: leaked $= 3 \times 64 = 192$ bytes $3$ blocks mein; reachable $= 7 \times 64 = 448$ bytes. ✓

Example 12 — Exam twist: kyun `-O2` bug chhupaata hai (Cell 12)

Forecast: bug gayab nahi hua — toh report clean kyun hai?

Dead-store elimination. Optimiser dekhta hai ki a[5] pe likhi value kabhi read nahi hoti, toh store ko poora delete kar deta hai. Yeh step kyun? Undefined Behaviour in C ke under compiler assume kar sakta hai ki koi out-of-bounds write nahi hoti; koi observable effect nahi, toh instruction remove kar deta hai.
No memory access ⇒ Memcheck ke liye instrument karne ko kuch nahi. Valgrind sirf wahi accesses check kar sakta hai jo run tak survive karte hain. Yeh step kyun? Memcheck emitted machine code watch karta hai, tumhare source ko nahi.
Fix: pehle hamesha -O0 -g ke saath debug karo (dekho Debugging with GDB), phir release build alag se re-audit karo. AddressSanitizer (ASan) se cross-check karo, jo compile time pe instrument karta hai aur kuch aise cases pakad sakta hai jinhein optimiser reshape kar deta hai.

Verify (logical): eliminated accesses $= 1$ ; Memcheck jo accesses dekh sakta hai $= max (0, 1 - 1) = 0$ ⇒ zero reports. ✓

Recall Cover check: har symptom ke liye cell batao

"Invalid read, 0 bytes inside a free'd block" ::: Cell 3, use-after-free (A-bit) "4 bytes before a block of size 20" ::: Cell 2, underflow (A-bit, negative side) "Conditional jump depends on uninitialised value" ::: Cell 5, V-bit in control flow Unused variable mein garbage copy karne ke baad silent report ::: Cell 6, V-bits travel, no use "indirectly lost" 8 bytes ::: Cell 9, child sirf lost parent ke through reachable -O0 pe fail hone wala clean report under -O2 ::: Cell 12, dead-store elimination