Memory layout — text, data, BSS, heap, stack segments: Question bank

5.1.15 · D5 · Coding › C Programming › Memory layout — text, data, BSS, heap, stack segments

Traps se pehle zaruri vocabulary

Neeche kuch traps low-level Unix terms pe based hain. Unhe ek baar yahan define kar lete hain taaki page pe koi cheez use se pehle clear ho jaye.

Definition Char terms jo traps assume karte hain

Program break — ek single marker (ek address) jo kehta hai "brk-managed heap yahan khatam hoti hai." Heap sirf wo region hai jo uske start se break tak hoti hai. Do system calls isse move karte hain: brk(addr) break ko ek exact address pe set karta hai, aur sbrk(n) ise n bytes se upar bump karta hai (purana break return karta hai). malloc in calls ko under the hood call karta hai heap badhaane ke liye; break ka upar jaana = heap ka upar grow karna.
mmap region — chhote brk heap ko extend karne ki jagah, OS map kar sakta hai virtual memory ka ek fresh chunk, free middle mein kahin bhi, mmap system call ke zariye. Bade mallocs ye use karte hain, aur shared libraries (libc, etc.) ko mmap karke read-only + executable bana diya jaata hai taaki bahut saare programs ek hi copy share karein. Ye BSS ke upar stack hone ki jagah alag jagah land karte hain.
Guard page — stack ke far edge pe ek single page jo no access mark hota hai. Agar ek growing stack (ya koi huge local array) use touch kar le, toh CPU turant fault karta hai — wahi fault hota hai "stack overflow" crash. Ye OS ka lagaya hua ek tripwire hai taaki stack silently doosri memory ko smash na kar sake.
W^X ("write XOR eXecute") — ek page-permission rule: koi bhi page ya toh writable hota hai ya executable, dono ek saath nahi. Ye ek attacker ko memory mein bytes likhne aur phir unhe code ki tarah run karne se rokta hai. Text/rodata pages executable-not-writable hote hain; stack/heap pages writable-not-executable hote hain.

Woh picture jise tum drill kar rahe ho

Traps se pehle, layout apni aankhon mein fix karo. Ye virtual address space hai jo ek process dekhti hai — bytes ka ek lamba column, sabse chhota address neeche, sabse bada upar. Figure 1 poora map hai, jisme read-only rodata section aur sabse upar kernel region bhi shaamil hai.

Figure — Memory layout — text, data, BSS, heap, stack segments

Figure 1 — Full user address space (low → high). Text, rodata, Data, BSS, brk heap, shared mmap/library region, stack, aur sabse upar kernel band jo user code touch nahi kar sakta.

Definition Segments ek nazar mein (low → high address)

Text (code) — compile ki hui machine instructions; read-only aur processes ke beech shareable.
rodata (read-only data) — constants aur string literals ke liye apna alag read-only section (const data, "hello"). Ye Data jaisa nahi hai, chahe dono initialized bytes hold karte hain.
Data — global/static variables jo non-zero value se initialize hote hain; wo bytes disk pe store hoti hain aur writable hoti hain.
BSS — global/static variables jo zero ya uninitialized hote hain; file mein sirf ek size record hota hai, aur OS load ke waqt zero-fill karta hai.
Heap — runtime pe malloc se liya gaya memory; brk heap higher addresses ki taraf grow karta hai jab program break upar jaata hai (vocabulary box dekho).
mmap / shared-library region — mapped chunks (large allocations, libc aur doosre shared objects) free middle mein place hote hain, BSS ke upar nahi.
Stack — function frames (params, return address, locals); lower addresses ki taraf grow karta hai (stack pointer neeche jaata hai), edge pe ek guard page ke saath.
Kernel space — sabse upar ke addresses kernel ke liye reserved hain aur user code ke liye inaccessible hain; unhe read/write karne ki koi bhi koshish fault karti hai.

Figure 2 ek dynamic idea capture karta hai jis par poori page depend karti hai: heap aur stack ek shared gap mein opposite ends se expand hote hain, jahan chhota brk heap hota hai, aur jahan large mmap blocks actually land karte hain.

Figure 2 — Heap vs stack ek shared gap mein grow karte hue. Program break neeche se upar jaata hai, stack pointer upar se neeche aata hai, mmap blocks side mein land karte hain, aur guard page woh point mark karta hai jahan collision crash ban jaata hai.

True ya false — justify karo

Ek uninitialized global int g; mein garbage hota hai jab tak tum ise assign nahi karte.

False — globals aur statics BSS mein rehte hain aur C standard guarantee karta hai ki ye zero se start hote hain; sirf automatic (stack) variables mein garbage hota hai.

Ek global int x = 0; Data segment mein rehta hai kyunki tumne initializer likha.

False — explicit = 0 bhi all-zero information hai, isliye compiler ise BSS mein rakhta hai, Data mein nahi; sirf non-zero initializers Data force karte hain.

BSS runtime pe Data se kam RAM use karta hai.

False — saving sirf disk pe hoti hai; load time pe OS BSS ko RAM mein exactly Data jaisi reserve aur zero-fill karta hai, isliye runtime memory same hoti hai.

Text segment read-only hai isliye viruses ek running program mein code inject nahi kar sakte.

Mostly true — W^X (write XOR execute; vocabulary box dekho) ke under Text pages executable-not-writable hote hain, isliye apni instructions overwrite karna fault karta hai; lekin attackers phir bhi control flow hijack karke execution kahin aur redirect kar sakte hain (dekho Buffer overflow and stack smashing).

Heap aur stack ka ek fixed, pre-assigned size boundary hota hai unke beech mein.

False — ye ek shared gap ke through ek doosre ki taraf grow karte hain isliye dono mein se koi bhi zyaadatar free space consume kar sakta hai; "boundary" dynamic hai aur sirf collision mein reach hoti hai.

static int s = 0; ek function ke andar stack pe rehta hai kyunki ye locally declare kiya gaya hai.

False — static static storage duration deta hai, isliye s BSS mein rehta hai (zero init) aur calls ke across persist karta hai; sirf uska scope local hai.

Do processes jo same program run kar rahe hain, ek Text segment ki copy share karte hain.

True — instructions running ke dauraan kabhi nahi badalte, isliye OS ek read-only physical copy dono mein map karta hai, memory bachata hai (dekho Virtual memory and paging); shared libraries bhi mmap se isi tarah share hoti hain.

Successive malloc calls hamesha pichle se zyaada higher addresses return karti hain.

False — trend upar ka hota hai jaise program break badhta hai, lekin freed blocks, allocator bins, aur mmap-backed large allocations lower ya scattered addresses de sakte hain.

malloc se return hua pointer tab destroy ho jaata hai jab wo function return karta hai jisne malloc call kiya tha.

False — stack pe pointer variable khatam hota hai, lekin heap block jo us par point kiya tha wo survive karta hai; agar koi doosra pointer ise hold nahi karta, tumne memory leak kar diya.

Stack overflow aur heap ka khatam hona same "out of memory" condition hai.

False — stack overflow tab hota hai jab stack pointer apna guard page cross karta hai (deep recursion / huge locals); heap exhaustion tab hota hai jab malloc NULL return karta hai. Alag segments, alag symptoms.

Kernel tumhare program ke address space ke middle mein kahin hota hai.

False — kernel sabse upar ke addresses mein map hota hai, user code se wall kar ke; wahan user read/write fault karta hai. Tumhara code, heap aur stack sab uske neeche hain.

Error dhundho

"Uninitialized globals unpredictable hote hain, isliye main unhe safety ke liye hamesha zero se initialize karta hoon."

Zero-init redundant hai — standard already BSS globals ko zero karta hai — aur isse bura, = 0 use Data mein move nahi karta vaise bhi. Habit harmful nahi hai, lekin reasoning (ki ye unsafe tha) galat hai.

"Maine ek huge int buf[1000000]; global banaya, isliye meri executable file 4 MB badh gayi."

Galat — ek all-zero (ya uninitialized) global BSS mein jaata hai, jo sirf ek size record store karta hai; file mushkil se badhti hai. Ek non-zero initializer dalo aur tab wo Data segment ke zariye bloat hoti hai.

"Function return ke baad memory rakhne ke liye, maine array ko function ke andar static declare kiya."

Ye memory rakhta zaroor hai (static storage), lekin array ek single fixed instance hai jo saari calls mein share hoti hai — har baar ek fresh block nahi. Per-call surviving memory ke liye heap use karo.

"Mera program stack overflow se crash hua, isliye maine stack space release karne ke liye free() call kiya."

free sirf heap blocks release karta hai aur stack pe kuch nahi karta. Stack frames return pe automatically reclaim hote hain; fix hai kam recursion depth ya chhote locals, free nahi.

"Maine ek function se &local return kiya aur caller ne use theek se use kiya, isliye stack addresses return karna kaam karta hai."

Ye luck se kaam kiya — local stack pe hai aur uska frame return ke baad gone hai, isliye pointer dangling hai (dekho Pointers and dangling pointers); memory kabhi bhi overwrite ho sakti hai.

"char *msg = "hello"; — main safely msg[0] = 'H' kar sakta hoon."

String literal read-only rodata section mein rehti hai, isliye usmein likhna undefined behavior hai (aksar crash). Agar modify karna hai toh pehle use stack ya heap buffer mein copy karo.

Why questions

Globals ko do segments (Data aur BSS) mein kyun split karte hain ek ki jagah?

Kyunki zero-valued data mein disk pe store karne ke liye koi information nahi hoti — BSS sirf "N bytes reserve karo, 0 se fill karo" record karta hai, executable ko chhota rakhta hai jabki Data actual non-zero bytes store karta hai.

Stack neeche kyun grow karta hai (lower addresses ki taraf) jabki heap upar grow karta hai?

Taaki dono ek bade middle gap share kar sakein aur ek doosre ki taraf expand kar sakein; kisi ko bhi hard pre-set size ki zaroorat nahi, aur ye sirf extreme cases mein collide karte hain.

Stack memory automatically free kyun ho jaati hai lekin heap memory nahi?

Stack strictly LIFO hai — ek return simply stack pointer ko wapis move karta hai (dekho Stack frames and the calling convention). Heap mein aisa koi order nahi hai; sirf tum jaante ho ki block se kab done ho, isliye tumhe free call karna padta hai.

Text segment ko alag kyun rakha jaata hai aur read-only kyun mark kiya jaata hai?

Code ko alag karne se bahut saari processes ek immutable copy share kar sakti hain, aur W^X ke under MMU un pages ko non-writable mark karta hai taaki instructions pe accidental ya malicious writes fault karein (dekho Virtual memory and paging).

Local variables aksar malloced blocks se bahut higher addresses kyun dikhate hain?

Stack user space ke high end ke paas hota hai (kernel band ke bilkul neeche) aur brk heap BSS ke upar low addresses se upar grow karta hai, isliye ek snapshot mein aksar stack addresses heap se kaafi upar dikhte hain.

C standard statics ke liye zero guarantee karta hai lekin locals ke liye nahi, kyun?

Statics/globals ek baar load pe BSS zero-fill karke set up hote hain — cheap aur deterministic. Har call pe har stack frame ko zero karna time lagaata, isliye locals mein jo bhi bytes the wahi rehte hain.

Shared libraries ko copy karne ki jagah mmap kyun kiya jaata hai?

mmap karke ek library ko read-only karne se har process same physical pages map kar sakti hai, isliye libc ki ek copy sab ke liye kaam karti hai — Text segment jaisi hi sharing trick.

Edge cases

Ek global array jo declare toh hai lekin kabhi use nahi hua: kya ye runtime pe RAM consume karta hai?

Haan agar compiler/linker ise rakhta hai — BSS phir bhi load time pe uske bytes reserve aur zero karta hai; aggressive dead-code elimination truly unreferenced waalon ko drop kar sakti hai.

int *p = malloc(0); — kahan kuch bhi rehta hai, aur kya p usable hai?

Pointer variable p khud stack pe rehta hai, lekin malloc jo bhi bytes reserve karta hai wo heap se aate hain; malloc(0) NULL ya ek unique non-dereferenceable pointer return kar sakta hai, isliye iske through read/write karna undefined hai — sirf free(p) safe hai.

Ek recursion bina base case ke: kaun sa segment fill up hota hai aur kya hota hai?

Har call stack pe ek naya frame push karta hai, stack pointer ko neeche le jaata hai jab tak ye guard page hit na kar le → stack overflow (crash), chahe kitna bhi heap free ho.

Kya heap kabhi Data/BSS region ke kisi hisse se lower address occupy kar sakta hai?

Classic model mein nahi — brk heap BSS ke bilkul upar se shuru hota hai jaise program break badhta hai; lekin mmap ke zariye bade allocations middle mein kahin land karte hain, isliye "BSS ke hamesha upar" rule sirf brk-based heap ke liye sahi hai.

Tum free(p) karte ho phir *p read karte ho. Kaun sa segment involved hai aur ye dangerous kyun hai?

Block physically abhi bhi heap pe hai, lekin ownership allocator ko wapis gayi, isliye p dangling hai; bytes kabhi bhi reuse ya scramble ho sakte hain (dekho Pointers and dangling pointers).

static const int table[] = {1,2,3}; — Data ya BSS ya kuch aur?

Iske non-zero initializers hain, isliye ye BSS nahi hai; kyunki ye const hai ye typically writable Data ki jagah read-only rodata section mein land karta hai.

Kya user code address space ke top pe kernel-space addresses read kar sakta hai?

Nahi — wo pages kernel-only mark hote hain; user-mode read ya write wahan ek protection fault trigger karta hai, aur yahi kernel ko stray pointers se safe rakhta hai.

Connections

Static and global variables — storage duration — Data-vs-BSS decision rules.
malloc, calloc, realloc and free — heap lifetime aur upar ke traps.
Pointers and dangling pointers — returning-stack-address aur use-after-free traps.
Stack frames and the calling convention — stack self-clean kyun hota hai.
Virtual memory and paging — pages, permissions, mmap aur kernel split.
Buffer overflow and stack smashing — read-only Text full protection kyun nahi hai.