Software Engineering — MCQ Practice

Hindi aur English dono mein practice karo — click karo answer check karne ke liye

📚 230 Questions 🌐 Hindi + English ✅ Free
भाषा / Language:
230 questions
211
EN + हिं Easy
GB What is 'memory debugging' with AddressSanitizer (ASan) and what categories of bugs does it detect that valgrind also detects?
IN एड्रेससैनिटाइज़र (एएसएएन) के साथ 'मेमोरी डिबगिंग' क्या है और यह किस श्रेणी के बग का पता लगाता है जिनका वेलग्रिंड भी पता लगाता है?
A
ASan only detects memory leaks; valgrind only detects null pointer dereferences ASan केवल मेमोरी लीक का पता लगाता है; वालग्रिंड केवल शून्य सूचक डीरेफ़रेंस का पता लगाता है
B
Both ASan and Valgrind detect: use-after-free, heap buffer overflows, stack buffer overflows, use of uninitialised memory — ASan is 2x slower than uninstrumented code; Valgrind is 10-50x slower, making ASan more practical for CI use while Valgrind offers more detailed analysis ASan और Valgrind दोनों पता लगाते हैं: उपयोग-बाद-मुक्त, हीप बफ़र ओवरफ़्लो, स्टैक बफ़र ओवरफ़्लो, अनइनिशियलाइज़्ड मेमोरी का उपयोग - ASan अनइंस्ट्रूमेंटेड कोड की तुलना में 2x धीमा है; वैलग्रिंड 10-50x धीमा है, जो सीआई उपयोग के लिए एएसएएन को अधिक व्यावहारिक बनाता है जबकि वैलग्रिंड अधिक विस्तृत विश्लेषण प्रदान करता है
C
ASan can only instrument programs compiled with GCC; Valgrind works with any executable एएसएएन केवल जीसीसी के साथ संकलित कार्यक्रमों को लिख सकता है; वालग्रिंड किसी भी निष्पादन योग्य के साथ काम करता है
D
Memory debugging tools are only needed for programs over 100,000 lines of code मेमोरी डिबगिंग टूल की आवश्यकता केवल 100,000 लाइनों से अधिक कोड वाले प्रोग्राम के लिए होती है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Use-after-free: access memory after free(). Heap overflow: write past end of malloc'd buffer. Stack overflow: write past end of stack array. Valgrind's Memcheck instruments at binary level (no recompile) with very detailed output but 10-50x overhead. ASan compiles instrumentation directly into the binary (2x overhead), making it feasible in CI pipelines. Both are essential tools for C/C++ code quality.
व्याख्या (हिन्दी) उपयोग-बाद-मुक्त: मुफ़्त के बाद मेमोरी तक पहुंचें()। हीप ओवरफ़्लो: मॉलोक्ड बफ़र का पिछला अंत लिखें। स्टैक ओवरफ्लो: स्टैक ऐरे का पिछला अंत लिखें। वेलग्रिंड के मेमचेक उपकरण बाइनरी स्तर पर (कोई पुन: संकलन नहीं) बहुत विस्तृत आउटपुट के साथ लेकिन 10-50x ओवरहेड। एएसएएन इंस्ट्रूमेंटेशन को सीधे बाइनरी (2x ओवरहेड) में संकलित करता है, जिससे यह सीआई पाइपलाइनों में संभव हो जाता है। दोनों C/C++ कोड गुणवत्ता के लिए आवश्यक उपकरण हैं।
212
EN + हिं Easy
GB What is the 'Heisenbug' phenomenon in software debugging and what commonly causes it?
IN सॉफ़्टवेयर डिबगिंग में 'हेइज़नबग' घटना क्या है और आमतौर पर इसका कारण क्या है?
A
A bug only occurring in production, never in development or staging बग केवल उत्पादन में होता है, विकास या स्टेजिंग में कभी नहीं
B
A defect that disappears or changes behaviour when you attempt to observe or debug it — commonly caused by timing-dependent race conditions that the debugger's pausing alters एक दोष जो गायब हो जाता है या जब आप इसे देखने या डिबग करने का प्रयास करते हैं तो व्यवहार बदल जाता है - आमतौर पर समय-निर्भर दौड़ स्थितियों के कारण होता है जो डिबगर के रुकने से बदल जाता है
C
A security vulnerability impossible to patch without replacing hardware हार्डवेयर को बदले बिना एक सुरक्षा भेद्यता को ठीक करना असंभव है
D
A bug introduced by the debugger tool itself डिबगर टूल द्वारा ही पेश किया गया एक बग
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Named after Heisenberg's uncertainty principle, Heisenbugs arise in concurrent code where race conditions depend on precise execution timing. Attaching a debugger introduces delays that change thread interleaving, eliminating the exact conditions causing the bug.
व्याख्या (हिन्दी) हाइजेनबर्ग के अनिश्चितता सिद्धांत के नाम पर, हाइजेनबग्स समवर्ती कोड में उत्पन्न होते हैं जहां दौड़ की स्थिति सटीक निष्पादन समय पर निर्भर करती है। डिबगर संलग्न करने से देरी होती है जो थ्रेड इंटरलीविंग को बदल देती है, जिससे बग पैदा करने वाली सटीक स्थितियाँ समाप्त हो जाती हैं।
213
EN + हिं Easy
GB What is 'rubber duck debugging' and what cognitive principle does it exploit?
IN 'रबर डक डिबगिंग' क्या है और यह किस संज्ञानात्मक सिद्धांत का उपयोग करता है?
A
A waterfall-era technique for testing on limited memory hardware सीमित मेमोरी हार्डवेयर पर परीक्षण के लिए एक वॉटरफॉल-युग तकनीक
B
Explaining code step-by-step to an inanimate object; the act of articulating the problem forces explicit processing revealing the solution — exploiting the principle that verbalisation activates different reasoning pathways किसी निर्जीव वस्तु को चरण-दर-चरण कोड समझाना; समस्या को स्पष्ट करने का कार्य स्पष्ट प्रसंस्करण को समाधान प्रकट करने के लिए मजबूर करता है - इस सिद्धांत का शोषण करते हुए कि मौखिककरण विभिन्न तर्क मार्गों को सक्रिय करता है
C
A formal IEEE-standard debugging technique requiring peer review documentation एक औपचारिक आईईईई-मानक डिबगिंग तकनीक जिसके लिए सहकर्मी समीक्षा दस्तावेज़ की आवश्यकता होती है
D
Testing using voice-controlled hardware like Amazon Echo अमेज़ॅन इको जैसे ध्वनि-नियंत्रित हार्डवेयर का उपयोग करके परीक्षण
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Rubber duck debugging works because explaining code to a non-expert forces you to articulate assumptions and skip no steps. This shifts from pattern-recognition mode to sequential explanation mode, often revealing incorrect assumptions through metacognition.
व्याख्या (हिन्दी) रबर डक डिबगिंग काम करती है क्योंकि किसी गैर-विशेषज्ञ को कोड समझाना आपको धारणाओं को स्पष्ट करने के लिए मजबूर करता है और कोई भी कदम नहीं छोड़ता है। यह पैटर्न-पहचान मोड से अनुक्रमिक स्पष्टीकरण मोड में स्थानांतरित हो जाता है, अक्सर मेटाकॉग्निशन के माध्यम से गलत धारणाओं को प्रकट करता है।
214
EN + हिं Easy
GB In multithreaded debugging, what is a 'deadlock' and what four Coffman conditions must simultaneously hold?
IN मल्टीथ्रेडेड डिबगिंग में, 'गतिरोध' क्या है और कौन सी चार कॉफ़मैन स्थितियाँ एक साथ होनी चाहिए?
A
Program runs out of memory; Coffman conditions are CPU, RAM, I/O, network saturation प्रोग्राम की स्मृति समाप्त हो जाती है; कॉफ़मैन स्थितियाँ सीपीयू, रैम, आई/ओ, नेटवर्क संतृप्ति हैं
B
Two or more threads permanently blocked waiting for each other; Coffman conditions: mutual exclusion, hold and wait, no preemption, and circular wait — all four must hold simultaneously दो या दो से अधिक थ्रेड एक-दूसरे की प्रतीक्षा में स्थायी रूप से अवरुद्ध हो गए हैं; कॉफ़मैन की शर्तें: पारस्परिक बहिष्कार, रोकें और प्रतीक्षा करें, कोई छूट नहीं, और परिपत्र प्रतीक्षा - इन चारों को एक साथ रखना होगा
C
Program enters infinite loop consuming all CPU time प्रोग्राम सभी सीपीयू समय का उपभोग करते हुए अनंत लूप में प्रवेश करता है
D
Exactly two threads deadlock; three or more cannot बिल्कुल दो धागे गतिरोध; तीन या अधिक नहीं कर सकते
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Coffman et al. showed deadlock requires all four conditions simultaneously: 1) Mutual exclusion, 2) Hold and wait, 3) No preemption, 4) Circular wait. Breaking any one prevents deadlock — resource ordering breaks circular wait; timeouts enable preemption.
व्याख्या (हिन्दी) कॉफ़मैन एट अल. दिखाया गया है कि गतिरोध के लिए सभी चार स्थितियों की एक साथ आवश्यकता होती है: 1) पारस्परिक बहिष्कार, 2) रुकें और प्रतीक्षा करें, 3) कोई छूट नहीं, 4) परिपत्र प्रतीक्षा। किसी एक को तोड़ने से गतिरोध रुकता है - संसाधन क्रम चक्रीय प्रतीक्षा को तोड़ता है; टाइमआउट प्रीएम्प्शन को सक्षम बनाता है।
215
EN + हिं Easy
GB What is 'binary search debugging' and in what scenario is it most effective?
IN 'बाइनरी सर्च डिबगिंग' क्या है और यह किस परिदृश्य में सबसे प्रभावी है?
A
Uses two debuggers simultaneously to find bugs in half the time आधे समय में बग ढूंढने के लिए एक साथ दो डिबगर्स का उपयोग करता है
B
Systematically halves the search space by inserting diagnostic checks at midpoints to determine which half contains the fault — most effective when fault location is unknown in a large codebase or long sequence of operations यह निर्धारित करने के लिए कि किस आधे हिस्से में गलती है, मध्य बिंदुओं पर नैदानिक ​​जांच डालकर खोज स्थान को व्यवस्थित रूप से आधा कर देता है - सबसे प्रभावी जब बड़े कोडबेस या संचालन के लंबे अनुक्रम में गलती का स्थान अज्ञात होता है
C
Only works with sorted data structures and linked lists केवल क्रमबद्ध डेटा संरचनाओं और लिंक की गई सूचियों के साथ काम करता है
D
A tool built into GDB for finding memory corruption स्मृति भ्रष्टाचार का पता लगाने के लिए जीडीबी में निर्मित एक उपकरण
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) 'git bisect' implements binary search debugging for version history: given known-good and known-bad commits, it checks midpoint commits to bisect the fault-introducing commit in O(log n) steps. Applied to code, inserting assertions at midpoints narrows fault location logarithmically.
व्याख्या (हिन्दी) 'गिट बाइसेक्ट' संस्करण इतिहास के लिए बाइनरी सर्च डिबगिंग लागू करता है: ज्ञात-अच्छे और ज्ञात-बुरे कमिट को देखते हुए, यह ओ (लॉग एन) चरणों में गलती-परिचय कमिट को बाइसेक्ट करने के लिए मध्यबिंदु कमिट की जांच करता है। कोड पर लागू, मध्यबिंदु पर अभिकथन डालने से गलती का स्थान लघुगणकीय रूप से कम हो जाता है।
216
EN + हिं Medium
GB What is 'post-mortem debugging' and what types of information does it rely on?
IN 'पोस्ट-मॉर्टम डिबगिंग' क्या है और यह किस प्रकार की जानकारी पर निर्भर करती है?
A
Analyses software after the project has been decommissioned परियोजना के बंद होने के बाद सॉफ्टवेयर का विश्लेषण करता है
B
Analyses a program's state after it has crashed or terminated abnormally, relying on core dumps, crash logs, exception stack traces, and memory snapshots captured at the moment of failure किसी प्रोग्राम के क्रैश होने या असामान्य रूप से समाप्त होने के बाद उसकी स्थिति का विश्लेषण करता है, जो विफलता के समय कैप्चर किए गए कोर डंप, क्रैश लॉग, अपवाद स्टैक ट्रेस और मेमोरी स्नैपशॉट पर निर्भर करता है।
C
A retrospective meeting technique in agile teams after a failed sprint असफल स्प्रिंट के बाद चुस्त टीमों में पूर्वव्यापी बैठक तकनीक
D
Requires program to be restarted and bug reproduced in controlled environment प्रोग्राम को पुनः आरंभ करने और नियंत्रित वातावरण में बग को पुन: उत्पन्न करने की आवश्यकता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Post-mortem (offline) debugging is the only option when a crash occurs in production where a live debugger cannot be attached. Core dumps capture complete process memory at crash time; stack traces show the call chain; structured logs provide execution history.
व्याख्या (हिन्दी) जब उत्पादन में कोई क्रैश होता है, जहां लाइव डिबगर संलग्न नहीं किया जा सकता है, तो पोस्ट-मॉर्टम (ऑफ़लाइन) डिबगिंग एकमात्र विकल्प है। कोर डंप क्रैश समय पर पूरी प्रक्रिया मेमोरी को कैप्चर करता है; स्टैक ट्रेस कॉल श्रृंखला दिखाते हैं; संरचित लॉग निष्पादन इतिहास प्रदान करते हैं।
217
EN + हिं Easy
GB What is 'delta debugging' and what problem does it solve in bug reproduction?
IN 'डेल्टा डिबगिंग' क्या है और यह बग पुनरुत्पादन में किस समस्या का समाधान करता है?
A
Compares difference between two source file versions to identify added bugs जोड़े गए बग की पहचान करने के लिए दो स्रोत फ़ाइल संस्करणों के बीच अंतर की तुलना करता है
B
Automatically minimises a failure-inducing input to the smallest possible failing case — solving the problem that bug reports contain complex large inputs where only a small portion causes the failure स्वचालित रूप से विफलता-उत्प्रेरण इनपुट को सबसे छोटे संभावित विफलता मामले में कम कर देता है - समस्या को हल करते हुए कि बग रिपोर्ट में जटिल बड़े इनपुट होते हैं जहां केवल एक छोटा सा हिस्सा विफलता का कारण बनता है
C
Computes performance difference between buggy and fixed versions छोटी गाड़ी और स्थिर संस्करणों के बीच प्रदर्शन अंतर की गणना करता है
D
Technique for finding bugs only occurring in incremental updates केवल वृद्धिशील अद्यतनों में होने वाले बग ढूंढने की तकनीक
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Andreas Zeller's delta debugging systematically reduces a failing test case. If a crash is reported with a 10MB XML file, delta debugging bisects the file, testing each half, recursively reducing to the minimal XML still triggering the crash — dramatically reducing debugging cognitive load.
व्याख्या (हिन्दी) एंड्रियास ज़ेलर की डेल्टा डिबगिंग व्यवस्थित रूप से एक असफल परीक्षण मामले को कम करती है। यदि 10 एमबी एक्सएमएल फ़ाइल के साथ क्रैश की सूचना दी जाती है, तो डेल्टा डिबगिंग फ़ाइल को दो भागों में विभाजित करती है, प्रत्येक आधे का परीक्षण करती है, पुनरावर्ती रूप से न्यूनतम एक्सएमएल को कम करती है जो अभी भी क्रैश को ट्रिगर करती है - डिबगिंग संज्ञानात्मक भार को नाटकीय रूप से कम करती है।
218
EN + हिं Medium
GB What is the 'divide and conquer' debugging strategy and why is it more efficient than sequential tracing?
IN 'फूट डालो और राज करो' डिबगिंग रणनीति क्या है और यह अनुक्रमिक अनुरेखण से अधिक कुशल क्यों है?
A
Divide and conquer debugging splits the codebase between two developers who debug simultaneously फूट डालो और जीतो डिबगिंग दो डेवलपर्स के बीच कोडबेस को विभाजित करती है जो एक साथ डिबग करते हैं
B
Divide and conquer debugging bisects the execution path — placing a checkpoint at the midpoint to determine which half contains the fault, then recursing on the faulty half — reducing search space from O(n) to O(log n) versus sequential line-by-line tracing फूट डालो और जीतो डिबगिंग निष्पादन पथ को द्विभाजित करती है - यह निर्धारित करने के लिए कि किस आधे में गलती है, मध्यबिंदु पर एक चेकपॉइंट रखकर, फिर दोषपूर्ण आधे पर पुनरावृत्ति - अनुक्रमिक लाइन-बाय-लाइन ट्रेसिंग बनाम ओ (एन) से ओ (लॉग एन) तक खोज स्थान को कम करना
C
Divide and conquer is only applicable to sorting algorithms, not general debugging फूट डालो और राज करो केवल सॉर्टिंग एल्गोरिदम पर लागू होता है, सामान्य डिबगिंग पर नहीं
D
Sequential tracing is always faster than divide and conquer for small codebases under 1000 lines 1000 लाइनों से कम के छोटे कोडबेस के लिए अनुक्रमिक अनुरेखण हमेशा विभाजित करने और जीतने की तुलना में तेज़ होता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) If a bug is in a 1000-line execution path, sequential tracing may require 1000 steps. Divide and conquer requires log2(1000) ≈ 10 checkpoints. This is why 'git bisect' (binary search over commits) finds the introducing commit in ~10 bisections across a 1000-commit history. The same principle applied to code via strategic assertion/log placement achieves the same logarithmic efficiency.
व्याख्या (हिन्दी) यदि कोई बग 1000-लाइन निष्पादन पथ में है, तो अनुक्रमिक ट्रेसिंग के लिए 1000 चरणों की आवश्यकता हो सकती है। फूट डालो और जीतो के लिए log2(1000) ≈ 10 चौकियों की आवश्यकता होती है। यही कारण है कि 'गिट बाइसेक्ट' (कमिट पर बाइनरी सर्च) 1000-प्रतिबद्ध इतिहास में ~10 द्विभाजनों में परिचयात्मक कमिट ढूंढता है। रणनीतिक अभिकथन/लॉग प्लेसमेंट के माध्यम से कोड पर लागू समान सिद्धांत समान लघुगणकीय दक्षता प्राप्त करता है।
219
EN + हिं Easy
GB What is a 'watchpoint' (data breakpoint) in debugging and what bug type makes it invaluable?
IN डिबगिंग में 'वॉचपॉइंट' (डेटा ब्रेकपॉइंट) क्या है और कौन सा बग प्रकार इसे अमूल्य बनाता है?
A
Watchpoint is a breakpoint that triggers when execution reaches a specific code line वॉचपॉइंट एक ब्रेकपॉइंट है जो तब ट्रिगर होता है जब निष्पादन एक विशिष्ट कोड लाइन तक पहुंचता है
B
A watchpoint triggers when a specific memory address or variable is read or written — invaluable for debugging data corruption bugs where a variable is being modified by an unknown code path that is hard to find by reading code जब एक विशिष्ट मेमोरी एड्रेस या वेरिएबल पढ़ा या लिखा जाता है तो वॉचपॉइंट ट्रिगर हो जाता है - डेटा भ्रष्टाचार बग को डीबग करने के लिए अमूल्य है जहां एक वेरिएबल को अज्ञात कोड पथ द्वारा संशोधित किया जा रहा है जिसे कोड पढ़कर ढूंढना मुश्किल है
C
Watchpoints are a JavaScript-only debugging feature not available in compiled languages वॉचप्वाइंट एक जावास्क्रिप्ट-केवल डिबगिंग सुविधा है जो संकलित भाषाओं में उपलब्ध नहीं है
D
Watchpoints are identical to conditional breakpoints and the terms are used interchangeably वॉचप्वाइंट सशर्त ब्रेकप्वाइंट के समान हैं और शब्दों का उपयोग परस्पर किया जाता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Classic data corruption scenario: a struct's field is being overwritten with garbage values and you can't find where. Setting a watchpoint on that memory address causes GDB/LLDB to stop execution exactly when and where the write occurs — regardless of which function, pointer chain, or code path is responsible. Without watchpoints, this class of bug may require hours of manual code tracing.
व्याख्या (हिन्दी) क्लासिक डेटा भ्रष्टाचार परिदृश्य: एक संरचना के क्षेत्र को कचरा मूल्यों के साथ अधिलेखित किया जा रहा है और आप यह नहीं ढूंढ पा रहे हैं कि कहां है। उस मेमोरी एड्रेस पर वॉचपॉइंट सेट करने से जीडीबी/एलएलडीबी ठीक उसी समय और जहां लेखन होता है, निष्पादन को रोक देता है - भले ही कौन सा फ़ंक्शन, पॉइंटर श्रृंखला या कोड पथ जिम्मेदार हो। वॉचपॉइंट के बिना, बग के इस वर्ग को मैन्युअल कोड ट्रेसिंग के घंटों की आवश्यकता हो सकती है।
220
EN + हिं Easy
GB What is 'logging strategy' in debugging and what are the trade-offs between too little and too much logging?
IN डिबगिंग में 'लॉगिंग रणनीति' क्या है और बहुत कम और बहुत अधिक लॉगिंग के बीच क्या अंतर है?
A
Logging strategy only matters for security-sensitive applications; other applications need minimal logging लॉगिंग रणनीति केवल सुरक्षा-संवेदनशील अनुप्रयोगों के लिए मायने रखती है; अन्य अनुप्रयोगों को न्यूनतम लॉगिंग की आवश्यकता होती है
B
Too little logging: insufficient context to diagnose production issues, forcing blind fixes; too much logging: performance degradation, storage costs, signal buried in noise, potential logging of sensitive data. Optimal: structured logs with configurable levels (ERROR/WARN/INFO/DEBUG) and correlation IDs बहुत कम लॉगिंग: उत्पादन समस्याओं का निदान करने के लिए अपर्याप्त संदर्भ, अंधाधुंध सुधारों को मजबूर करना; बहुत अधिक लॉगिंग: प्रदर्शन में गिरावट, भंडारण लागत, शोर में दबे सिग्नल, संवेदनशील डेटा की संभावित लॉगिंग। इष्टतम: विन्यास योग्य स्तरों (त्रुटि/चेतावनी/सूचना/डीबग) और सहसंबंध आईडी के साथ संरचित लॉग
C
More logging is always better; storage is cheap enough that all debug output should be retained permanently अधिक लॉगिंग हमेशा बेहतर होती है; भंडारण इतना सस्ता है कि सभी डिबग आउटपुट को स्थायी रूप से बनाए रखा जाना चाहिए
D
Logging should only be added after a bug is reported, not proactively during development लॉगिंग केवल बग रिपोर्ट होने के बाद ही जोड़ी जानी चाहिए, विकास के दौरान सक्रिय रूप से नहीं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Structured logging (JSON logs with request IDs, user IDs, timestamps, context fields) with log levels enables: ERROR always on (alerts), INFO for audit trails, DEBUG off in production (enable per-service for diagnosis). Correlation IDs trace requests across microservices. The key insight: log what you'll need to diagnose a failure you can't predict, not what you currently think might fail.
व्याख्या (हिन्दी) लॉग स्तरों के साथ संरचित लॉगिंग (अनुरोध आईडी, उपयोगकर्ता आईडी, टाइमस्टैम्प, संदर्भ फ़ील्ड के साथ JSON लॉग) सक्षम करता है: त्रुटि हमेशा चालू (अलर्ट), ऑडिट ट्रेल्स के लिए जानकारी, उत्पादन में डीबग बंद (निदान के लिए प्रति-सेवा सक्षम करें)। सहसंबंध आईडी माइक्रोसर्विसेज़ में अनुरोधों का पता लगाती हैं। मुख्य अंतर्दृष्टि: उस विफलता का निदान करने के लिए आपको जो चाहिए उसे लॉग करें जिसकी आप भविष्यवाणी नहीं कर सकते हैं, न कि वह जो आप वर्तमान में सोचते हैं कि विफल हो सकता है।
221
EN + हिं Easy
GB What is 'remote debugging' and what specific challenges does it introduce compared to local debugging?
IN 'रिमोट डिबगिंग' क्या है और यह स्थानीय डिबगिंग की तुलना में कौन सी विशिष्ट चुनौतियाँ प्रस्तुत करता है?
A
Remote debugging refers to debugging software written by a remote overseas development team रिमोट डिबगिंग से तात्पर्य दूरस्थ विदेशी विकास टीम द्वारा लिखे गए डिबगिंग सॉफ़्टवेयर से है
B
Remote debugging attaches a debugger to a process running on a different machine — introducing challenges: network latency making stepping slow, security risks from debug ports exposure, environment differences between local and remote, and inability to use memory-intensive debugging on production रिमोट डिबगिंग एक डिबगर को एक अलग मशीन पर चलने वाली प्रक्रिया से जोड़ता है - चुनौतियां पेश करता है: नेटवर्क विलंबता के कारण कदम धीमा हो जाता है, डिबग पोर्ट एक्सपोज़र से सुरक्षा जोखिम, स्थानीय और रिमोट के बीच पर्यावरण अंतर, और उत्पादन पर मेमोरी-सघन डिबगिंग का उपयोग करने में असमर्थता
C
Remote debugging is identical to local debugging except the IDE must be cloud-hosted रिमोट डिबगिंग स्थानीय डिबगिंग के समान है, सिवाय इसके कि आईडीई को क्लाउड-होस्ट किया जाना चाहिए
D
Remote debugging is prohibited in regulated industries because it exposes production data विनियमित उद्योगों में रिमोट डिबगिंग निषिद्ध है क्योंकि यह उत्पादन डेटा को उजागर करता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Docker and Kubernetes made remote debugging critical: services run in containers/pods unreproducible locally. SSH tunnelling + GDB remote, Java JPDA (JDWP protocol), Python debugpy, and Node.js (1, 1, 5, 69, 4, 'What is 'undefined behaviour' (UB) in C/C++ and why is it particularly dangerous from a debugging perspective?
व्याख्या (हिन्दी) डॉकर और कुबेरनेट्स ने रिमोट डिबगिंग को महत्वपूर्ण बना दिया है: कंटेनर/पॉड में चलने वाली सेवाएं स्थानीय स्तर पर अप्राप्य हैं। SSH टनलिंग + GDB रिमोट, जावा JPDA (JDWP प्रोटोकॉल), पायथन डिबगपी, और Node.js (1, 1, 5, 69, 4, 'सी/सी++ में 'अपरिभाषित व्यवहार' (यूबी) क्या है और डिबगिंग परिप्रेक्ष्य से यह विशेष रूप से खतरनाक क्यों है?
222
EN + हिं Easy
GB What is 'printf debugging' and what is its key limitation that debugger-based debugging overcomes?
IN 'प्रिंटफ डिबगिंग' क्या है और इसकी प्रमुख सीमा क्या है जिसे डिबगर-आधारित डिबगिंग खत्म कर देती है?
A
Printf debugging is a deprecated technique never used by professional software engineers प्रिंटफ़ डिबगिंग एक अप्रचलित तकनीक है जिसका उपयोग पेशेवर सॉफ़्टवेयर इंजीनियरों द्वारा कभी नहीं किया जाता है
B
Printf debugging inserts print statements to observe execution state — its key limitation is that it requires code modification and recompilation for each investigation step and cannot interactively explore state at runtime; debuggers allow inspection without code changes प्रिंटफ डिबगिंग निष्पादन स्थिति का निरीक्षण करने के लिए प्रिंट स्टेटमेंट सम्मिलित करता है - इसकी मुख्य सीमा यह है कि इसमें प्रत्येक जांच चरण के लिए कोड संशोधन और पुनर्संकलन की आवश्यकता होती है और रनटाइम पर इंटरैक्टिव रूप से स्थिति का पता नहीं लगाया जा सकता है; डिबगर्स कोड परिवर्तन के बिना निरीक्षण की अनुमति देते हैं
C
Printf debugging is superior to debuggers for multithreaded programs because it is non-intrusive प्रिंटफ डिबगिंग मल्टीथ्रेडेड प्रोग्राम के लिए डिबगर्स से बेहतर है क्योंकि यह गैर-घुसपैठकारी है
D
Printf debugging is only possible in languages with a built-in print function Printf डिबगिंग केवल अंतर्निहित प्रिंट फ़ंक्शन वाली भाषाओं में ही संभव है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Printf debugging is actually widely used even by experienced engineers — especially in distributed systems where attaching a debugger is impractical. Its limitation: each new piece of information requires a code change, rebuild, and redeploy cycle. Debuggers allow interactive inspection of any variable, stack frame, or memory address without touching the code — enabling much faster investigation cycles for local bugs.
व्याख्या (हिन्दी) प्रिंटफ डिबगिंग वास्तव में अनुभवी इंजीनियरों द्वारा भी व्यापक रूप से उपयोग किया जाता है - विशेष रूप से वितरित सिस्टम में जहां डिबगर संलग्न करना अव्यावहारिक है। इसकी सीमा: प्रत्येक नई जानकारी के लिए कोड परिवर्तन, पुनर्निर्माण और पुन: तैनाती चक्र की आवश्यकता होती है। डिबगर्स कोड को छुए बिना किसी भी वेरिएबल, स्टैक फ्रेम या मेमोरी एड्रेस के इंटरैक्टिव निरीक्षण की अनुमति देते हैं - स्थानीय बग के लिए बहुत तेज़ जांच चक्र सक्षम करते हैं।
223
EN + हिं Medium
GB What is 'snapshot debugging' and how does it differ from traditional live debugging?
IN 'स्नैपशॉट डिबगिंग' क्या है और यह पारंपरिक लाइव डिबगिंग से कैसे भिन्न है?
A
Snapshot debugging creates database backups at regular intervals during development स्नैपशॉट डिबगिंग विकास के दौरान नियमित अंतराल पर डेटाबेस बैकअप बनाता है
B
Snapshot debugging captures a complete program state snapshot at the point of failure (variables, call stack, heap) without pausing execution — allowing post-hoc investigation without interrupting service; traditional debugging pauses execution interactively but requires the process to be running स्नैपशॉट डिबगिंग निष्पादन को रोके बिना विफलता के बिंदु (वेरिएबल, कॉल स्टैक, हीप) पर एक पूर्ण प्रोग्राम स्थिति स्नैपशॉट कैप्चर करता है - सेवा में बाधा डाले बिना पोस्ट-हॉक जांच की अनुमति देता है; पारंपरिक डिबगिंग अंतःक्रियात्मक रूप से निष्पादन को रोकती है लेकिन प्रक्रिया को चालू रखने की आवश्यकता होती है
C
Snapshot debugging is identical to core dump analysis and both terms describe the same technique स्नैपशॉट डिबगिंग कोर डंप विश्लेषण के समान है और दोनों शब्द एक ही तकनीक का वर्णन करते हैं
D
Snapshot debugging is only available in cloud platforms like Azure and AWS स्नैपशॉट डिबगिंग केवल Azure और AWS जैसे क्लाउड प्लेटफ़ॉर्म में उपलब्ध है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Tools like Visual Studio Snapshot Debugger (Azure), Lightrun, and Rookout enable production debugging by capturing full execution context when a specific line is hit — without stopping the process. This solves the production debugging paradox: traditional debuggers interrupt service; logging lacks detail; snapshot debugging captures complete state non-intrusively. Developers can inspect any variable value at the failure point hours after it occurred.
व्याख्या (हिन्दी) विज़ुअल स्टूडियो स्नैपशॉट डिबगर (एज़्योर), लाइटरन और रूकआउट जैसे उपकरण प्रक्रिया को रोके बिना, एक विशिष्ट लाइन हिट होने पर पूर्ण निष्पादन संदर्भ को कैप्चर करके उत्पादन डिबगिंग को सक्षम करते हैं। यह उत्पादन डिबगिंग विरोधाभास को हल करता है: पारंपरिक डिबगर्स सेवा को बाधित करते हैं; लॉगिंग में विवरण का अभाव है; स्नैपशॉट डिबगिंग पूरी स्थिति को बिना किसी हस्तक्षेप के कैप्चर करता है। डेवलपर्स किसी भी वैरिएबल मान का उसके घटित होने के कुछ घंटों बाद विफलता बिंदु पर निरीक्षण कर सकते हैं।
224
EN + हिं Easy
GB What is 'differential debugging' and when is it most effectively applied?
IN 'डिफ़रेंशियल डिबगिंग' क्या है और इसे सबसे प्रभावी ढंग से कब लागू किया जाता है?
A
Differential debugging compares two developers' implementations of the same function डिफरेंशियल डिबगिंग एक ही फ़ंक्शन के दो डेवलपर्स के कार्यान्वयन की तुलना करती है
B
Differential debugging compares two configurations that exhibit different behaviour (buggy vs working, version A vs version B) — systematically varying one factor at a time to identify which difference causes the fault; most effective when a regression is known to exist between two states डिफरेंशियल डिबगिंग दो कॉन्फ़िगरेशन की तुलना करती है जो अलग-अलग व्यवहार प्रदर्शित करती है (छोटी गाड़ी बनाम काम करना, संस्करण ए बनाम संस्करण बी) - यह पहचानने के लिए कि कौन सा अंतर गलती का कारण बनता है, एक समय में व्यवस्थित रूप से एक कारक को बदलता है; सबसे प्रभावी तब होता है जब दो राज्यों के बीच एक प्रतिगमन मौजूद होता है
C
Differential debugging is a formal verification technique requiring mathematical proofs डिफरेंशियल डिबगिंग एक औपचारिक सत्यापन तकनीक है जिसके लिए गणितीय प्रमाण की आवश्यकता होती है
D
Differential debugging can only be applied to database query performance problems विभेदक डिबगिंग केवल डेटाबेस क्वेरी प्रदर्शन समस्याओं पर लागू की जा सकती है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) 'It worked yesterday, it doesn't today' — differential debugging is perfect here. git bisect performs differential debugging across commits. Environmental differential: 'works on my machine, fails on staging' — systematically compare OS, JVM version, library versions, environment variables, network configuration until the differing factor is found. The hypothesis: 'if X is the same in both environments, X is not the cause.'
व्याख्या (हिन्दी) 'इसने कल काम किया, आज नहीं किया' - यहां डिफरेंशियल डिबगिंग एकदम सही है। git bisect पूरे कमिट में डिफरेंशियल डिबगिंग करता है। पर्यावरणीय अंतर: 'मेरी मशीन पर काम करता है, स्टेजिंग पर विफल रहता है' - भिन्न कारक मिलने तक व्यवस्थित रूप से ओएस, जेवीएम संस्करण, लाइब्रेरी संस्करण, पर्यावरण चर, नेटवर्क कॉन्फ़िगरेशन की तुलना करें। परिकल्पना: 'यदि X दोनों वातावरणों में समान है, तो X इसका कारण नहीं है।'
225
EN + हिं Medium
GB What is 'assertion-driven debugging' and how does it prevent future regression of the same bug?
IN 'अभिकथन-संचालित डिबगिंग' क्या है और यह उसी बग के भविष्य के प्रतिगमन को कैसे रोकता है?
A
Assertion-driven debugging uses assert statements to automatically fix bugs at runtime अभिकथन-संचालित डिबगिंग रनटाइम पर बग को स्वचालित रूप से ठीक करने के लिए अभिकथन कथन का उपयोग करता है
B
Assertion-driven debugging adds runtime assertions that document the discovered invariant violated by the bug — after fixing the bug the assertion remains in the code, forming an executable specification that catches the same fault if it ever recurs अभिकथन-संचालित डिबगिंग रनटाइम अभिकथन जोड़ता है जो बग द्वारा उल्लंघन किए गए खोजे गए अपरिवर्तनीय दस्तावेज को दस्तावेज करता है - बग को ठीक करने के बाद अभिकथन कोड में रहता है, एक निष्पादन योग्य विनिर्देश बनाता है जो उसी गलती को पकड़ता है यदि यह कभी भी दोहराया जाता है
C
Assertion-driven debugging is identical to TDD and both terms describe the same practice अभिकथन-संचालित डिबगिंग टीडीडी के समान है और दोनों शब्द एक ही अभ्यास का वर्णन करते हैं
D
Assertions must always be removed from production builds to avoid performance overhead प्रदर्शन ओवरहेड से बचने के लिए दावे को हमेशा उत्पादन बिल्ड से हटा दिया जाना चाहिए
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) When you discover that a critical function was being called with a null parameter (causing crash), add: assert(param != null, 'param must not be null — see bug #1234'). This assertion: 1) documents the invariant for future readers, 2) catches the same bug immediately if the calling code regresses, 3) provides a specific error message that eliminates investigation time. This transforms a one-time fix into a permanent guard.
व्याख्या (हिन्दी) जब आपको पता चलता है कि एक महत्वपूर्ण फ़ंक्शन को शून्य पैरामीटर (क्रैश का कारण) के साथ कॉल किया जा रहा था, तो जोड़ें: ज़ोर (परम! = शून्य, 'परम शून्य नहीं होना चाहिए - बग #1234 देखें')। यह दावा: 1) भविष्य के पाठकों के लिए अपरिवर्तनीय दस्तावेज, 2) कॉलिंग कोड वापस आने पर तुरंत उसी बग को पकड़ लेता है, 3) एक विशिष्ट त्रुटि संदेश प्रदान करता है जो जांच के समय को समाप्त कर देता है। यह एक बार के फिक्स को स्थायी गार्ड में बदल देता है।
211–225 of 230