Noesis
1.2.39 · D5 · HinglishIntroduction to Programming (Python)

Question bank — Recursion depth limit — stack overflow

1,649 words7 min read↑ Read in English

1.2.39 · D5 · Coding › Introduction to Programming (Python) › Recursion depth limit — stack overflow

True or false — justify

Har recursive call exactly ek naya stack frame add karta hai.
True. Ek call beech kaam mein pause hoti hai, isliye uske locals, arguments aur return address ek nayi stack frame mein save karne padte hain jab tak inner call chal rahi ho — ek call, ek frame.
Ek sahi base case guarantee karta hai ki aap kabhi RecursionError nahi paoge.
False. Ek reachable base case infinite recursion ko rokta hai, lekin ek sahi-magar-deep recursion (jaise depth 2000) phir bhi ~1000-frame limit se pehle us tak pahunchne se pehle exceed kar deti hai.
RecursionError aur stack-overflow segfault ek hi crash hain.
False. RecursionError Python ki catchable soft-limit warning hai jo memory khatam hone se pehle fire hoti hai; segfault OS ka uncatchable hard crash hai jise rokne ke liye hi soft limit exist karti hai.
sys.setrecursionlimit() badhane se aapko zyada stack memory milti hai.
False. Ye sirf woh counter badhata hai jitna Python pahunchne ko taiyaar hai; actual stack memory (fixed, ~1–8 MB) unchanged rehti hai. Agar memory se zyada push karo toh segfault hoga hi.
Ek iterative loop ek stack frame use karta hai chahe kitni bhi baar repeat ho.
True. Ek loop ek single call ke andar rehta hai, wahi frame reuse karta hai; variables ko in-place update karta hai naye frames stack karne ki jagah, isliye depth 1 rehti hai.
Default recursion limit ka matlab hai ki aap hamesha 1000 apne recursive calls kar sakte ho.
False. Limit sabhi live frames count karti hai — REPL, module, caller. Agar pehle se exist karte hain, toh aapko roughly apne milenge.
RecursionError ko try/except se pakadna program ko gracefully recover karne deta hai.
True. Kyunki ye ek ordinary exception hai (OS signal nahi), try/except ise pakad sakta hai aur fallback return kar sakta hai — isliye hi Python soft limit use karta hai.
Do recursive branches (jaise fib(n-1) + fib(n-2)) recursion ki depth double kar dete hain.
False. Ye total calls ki sankhya multiply karte hain, lekin kisi bhi instant mein sirf ek hi path tree ke neeche active hota hai, isliye depth linearly badhti hai (≈ ), exponentially nahi.
Zyada recursion hamesha zyada heap memory use karta hai.
False. Frames stack par rehte hain, heap par nahi. Deep recursion stack par dabav daalta hai; heap usage depend karta hai aap kaunse objects allocate karte ho, jo ek alag concern hai (dekho Memory model — stack vs heap).
Python mein tail recursion stack ko badhne se rokta hai.
False. Python tail-call optimization nahi karta, isliye ek tail-recursive call bhi ek naya frame push karta hai — dekho Tail recursion and why Python lacks tail-call optimization.

Spot the error

def f(n): return f(n) — base case missing hai. Kya ye akela bug hai?
Missing base case cause hai, lekin deeper issue yeh hai: if n==0 jaisi base hone ke bawajood, f(n) (unchanged argument) ke saath call karna kabhi us tak pahunchti hi nahi — toh phir bhi forever loop karti.
def g(n):``if n == 0: return 0\` return g(n + 1) — base hai n==0. Safe?
Unsafe. Recursive step 0 se door ja raha hai (n badh raha hai), isliye positive start se base unreachable hai → guaranteed RecursionError.
sys.setrecursionlimit(10**9) ek broken infinite recursion se pehle — accha fix hai?
Nahi. Itna bada limit early warning hata deta hai aur runaway recursion ko real stack memory exhaust karne deta hai, ek debuggable RecursionError ko uncatchable segfault mein badal deta hai.
except RecursionError: ek call ke aas-paas jo pehle se 900 frames deep hai. Reliable?
Risky. Exception handle karne ke liye thodi stack room chahiye; agar aap bilkul ceiling par ho, toh except block bhi run karne mein fail ho sakta hai. Limit ke bilkul paas jaane ki bajaye headroom rakho.
def h(n): if n <= 0: return 0`` return n + h(n - 1)koh(2000)` ke saath call kiya. Kya galat hai?
Logically kuch nahi — base reachable hai aur approach ho raha hai. Bug purely depth ka hai: 2000 stacked frames default 1000 limit se zyada hain.

Why questions

Interpreter ko har frame mein return address store karne ki zaroorat kyun hai?
Taaki use pata ho ki current call return hone ke baad caller mein kahan resume karna hai — iske bina execution sahi jagah wापस nahi aa sakti.
Stack chhota (~1–8 MB) kyun hota hai jabki heap bada hota hai?
Stack ek fast, fixed, contiguous region hai call bookkeeping ke liye (sirf push/pop); heap ek large, flexible pool hai long-lived objects ke liye. Chhota size us speed aur simplicity ki keemat hai.
Python soft limit kyun choose karta hai OS ko program crash karne dene ki jagah?
Ek catchable RecursionError aapko debug, log, ya recover karne deta hai; ek raw OS segfault koi traceback nahi deta aur handle nahi ho sakta — soft limit graceful failure ke liye ek chhoti guardrail hai.
Recursion ko iteration mein convert karna depth problems kyun fix karta hai?
Iteration saara kaam ek frame ke andar rakhta hai aur variables in-place update karta hai, isliye koi frames pile up nahi hote — depth 1 rehti hai chahe input size kuch bhi ho (dekho Iteration vs Recursion).
Overflow ke liye "depth" "total calls ki sankhya" se zyada important kyun hai?
Overflow ek saath alive frames ke baare mein hai. Ek function jo ek million baar sequentially call hota hai (har ek return karne ke baad agli) kabhi stack nahi karta — sirf simultaneously-paused calls stack space consume karte hain.
Actual crash depth runs ya environments ke beech thodi alag kyun ho sakti hai?
Kyunki pehle se existing frames (REPL, imported modules, wrapping functions) alag-alag hote hain, aur limit sabhi frames count karti hai — toh aapki usable depth wahi shift ho jaati hai jo pehle se stack par hai.

Edge cases

Ek function ki recursion depth kya hai jo kabhi khud ko call nahi karta?
Jab tak chal raha hai ek (uska apna frame), aur ye kabhi overflow mein contribute nahi karta — "stacking" sense mein recursion depth effectively us se aage ke extra frames hain.
Base case n == 0 hai lekin function n = -1 se call hota hai 1 se ghatta ke. Kya hoga?
Ye base ko overshoot karta hai (-1, -2, -3, ...), kabhi 0 nahi hota, aur overflow karta hai. Robust code n <= 0 use karta hai taaki koi bhi starting side pakdi ja sake.
sys.setrecursionlimit(5) phir ek recursion jo depth 10 chahti hai. Kaunsa error, aur kya number "5" exact hai?
RecursionError fire hota hai, lekin aapki 5vi call par nahi — pre-existing frames bhi count hote hain, isliye ye almost turant trip kar sakta hai. Limit ek total-frame ceiling hai, per-function budget nahi.
Exactly limit depth ki recursion: kya ye hamesha crash karta hai, ya barely succeed ho sakta hai?
Ye borderline hai — kyunki limit sabhi frames count karti hai, ek aur frame fit hoga ya nahi ye depend karta hai kitne pehle se stacked the, isliye wahi code ek context mein pass ho sakta hai aur doosre mein raise kar sakta hai.
Mutual recursion (a calls b, b calls a) kya usi limit se hit hoti hai?
Haan. Limit har frame count karti hai chahe wo kisi bhi function ka ho, isliye do functions ke beech ping-pong karna frames utni hi tezi se stack karta hai jitna self-recursion.
Zero-argument ya constant recursion jaise def loop(): return loop() — depth pattern kya hai?
Depth exactly 1 per call badhti hai (koi argument nahi track karne ke liye "distance to base"), isliye ye seedha limit tak race karti hai aur RecursionError raise karti hai — ek pure "no base case" failure.
Recall Ek recursion par trust karne se pehle one-line safety checklist

Kya iska base case hai? ::: Hona chahiye, warna frames kabhi nahi rukenge. Kya har recursive call strictly us base ki taraf move karti hai? ::: Agar nahi, toh base unreachable hai aur aap phir bhi overflow karoge. Kya maximum depth comfortably ~1000 se kam hai? ::: Agar nahi, toh limit sirf finite depth ke liye badhao, ya iteratively rewrite karo.

Connections