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
196
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) परिपत्र प्रतीक्षा। किसी एक को तोड़ने से गतिरोध रुकता है - संसाधन क्रम चक्रीय प्रतीक्षा को तोड़ता है; टाइमआउट प्रीएम्प्शन को सक्षम बनाता है।
197
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.
व्याख्या (हिन्दी) 'गिट बाइसेक्ट' संस्करण इतिहास के लिए बाइनरी सर्च डिबगिंग लागू करता है: ज्ञात-अच्छे और ज्ञात-बुरे कमिट को देखते हुए, यह ओ (लॉग एन) चरणों में गलती-परिचय कमिट को बाइसेक्ट करने के लिए मध्यबिंदु कमिट की जांच करता है। कोड पर लागू, मध्यबिंदु पर अभिकथन डालने से गलती का स्थान लघुगणकीय रूप से कम हो जाता है।
198
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.
व्याख्या (हिन्दी) जब उत्पादन में कोई क्रैश होता है, जहां लाइव डिबगर संलग्न नहीं किया जा सकता है, तो पोस्ट-मॉर्टम (ऑफ़लाइन) डिबगिंग एकमात्र विकल्प है। कोर डंप क्रैश समय पर पूरी प्रक्रिया मेमोरी को कैप्चर करता है; स्टैक ट्रेस कॉल श्रृंखला दिखाते हैं; संरचित लॉग निष्पादन इतिहास प्रदान करते हैं।
199
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 एमबी एक्सएमएल फ़ाइल के साथ क्रैश की सूचना दी जाती है, तो डेल्टा डिबगिंग फ़ाइल को दो भागों में विभाजित करती है, प्रत्येक आधे का परीक्षण करती है, पुनरावर्ती रूप से न्यूनतम एक्सएमएल को कम करती है जो अभी भी क्रैश को ट्रिगर करती है - डिबगिंग संज्ञानात्मक भार को नाटकीय रूप से कम करती है।
200
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 द्विभाजनों में परिचयात्मक कमिट ढूंढता है। रणनीतिक अभिकथन/लॉग प्लेसमेंट के माध्यम से कोड पर लागू समान सिद्धांत समान लघुगणकीय दक्षता प्राप्त करता है।
201
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.
व्याख्या (हिन्दी) क्लासिक डेटा भ्रष्टाचार परिदृश्य: एक संरचना के क्षेत्र को कचरा मूल्यों के साथ अधिलेखित किया जा रहा है और आप यह नहीं ढूंढ पा रहे हैं कि कहां है। उस मेमोरी एड्रेस पर वॉचपॉइंट सेट करने से जीडीबी/एलएलडीबी ठीक उसी समय और जहां लेखन होता है, निष्पादन को रोक देता है - भले ही कौन सा फ़ंक्शन, पॉइंटर श्रृंखला या कोड पथ जिम्मेदार हो। वॉचपॉइंट के बिना, बग के इस वर्ग को मैन्युअल कोड ट्रेसिंग के घंटों की आवश्यकता हो सकती है।
202
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 लॉग) सक्षम करता है: त्रुटि हमेशा चालू (अलर्ट), ऑडिट ट्रेल्स के लिए जानकारी, उत्पादन में डीबग बंद (निदान के लिए प्रति-सेवा सक्षम करें)। सहसंबंध आईडी माइक्रोसर्विसेज़ में अनुरोधों का पता लगाती हैं। मुख्य अंतर्दृष्टि: उस विफलता का निदान करने के लिए आपको जो चाहिए उसे लॉग करें जिसकी आप भविष्यवाणी नहीं कर सकते हैं, न कि वह जो आप वर्तमान में सोचते हैं कि विफल हो सकता है।
203
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, 'सी/सी++ में 'अपरिभाषित व्यवहार' (यूबी) क्या है और डिबगिंग परिप्रेक्ष्य से यह विशेष रूप से खतरनाक क्यों है?
204
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.
व्याख्या (हिन्दी) प्रिंटफ डिबगिंग वास्तव में अनुभवी इंजीनियरों द्वारा भी व्यापक रूप से उपयोग किया जाता है - विशेष रूप से वितरित सिस्टम में जहां डिबगर संलग्न करना अव्यावहारिक है। इसकी सीमा: प्रत्येक नई जानकारी के लिए कोड परिवर्तन, पुनर्निर्माण और पुन: तैनाती चक्र की आवश्यकता होती है। डिबगर्स कोड को छुए बिना किसी भी वेरिएबल, स्टैक फ्रेम या मेमोरी एड्रेस के इंटरैक्टिव निरीक्षण की अनुमति देते हैं - स्थानीय बग के लिए बहुत तेज़ जांच चक्र सक्षम करते हैं।
205
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.
व्याख्या (हिन्दी) विज़ुअल स्टूडियो स्नैपशॉट डिबगर (एज़्योर), लाइटरन और रूकआउट जैसे उपकरण प्रक्रिया को रोके बिना, एक विशिष्ट लाइन हिट होने पर पूर्ण निष्पादन संदर्भ को कैप्चर करके उत्पादन डिबगिंग को सक्षम करते हैं। यह उत्पादन डिबगिंग विरोधाभास को हल करता है: पारंपरिक डिबगर्स सेवा को बाधित करते हैं; लॉगिंग में विवरण का अभाव है; स्नैपशॉट डिबगिंग पूरी स्थिति को बिना किसी हस्तक्षेप के कैप्चर करता है। डेवलपर्स किसी भी वैरिएबल मान का उसके घटित होने के कुछ घंटों बाद विफलता बिंदु पर निरीक्षण कर सकते हैं।
206
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 इसका कारण नहीं है।'
207
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) एक विशिष्ट त्रुटि संदेश प्रदान करता है जो जांच के समय को समाप्त कर देता है। यह एक बार के फिक्स को स्थायी गार्ड में बदल देता है।
208
EN + हिं
GB What is 'time-travel debugging' and what class of bugs benefits most from it?
IN 'टाइम-ट्रैवल डिबगिंग' क्या है और किस वर्ग के बग इससे सबसे अधिक लाभान्वित होते हैं?
A
Time-travel debugging resets the system clock to reproduce date-dependent bugs टाइम-ट्रैवल डिबगिंग दिनांक-निर्भर बग को पुन: उत्पन्न करने के लिए सिस्टम घड़ी को रीसेट करता है
B
Time-travel debugging records a complete execution trace allowing the debugger to step backwards as well as forwards through the execution history — most beneficial for bugs where the failure point is far removed from the causal fault (corruption happens at step 1, crash at step 10000) टाइम-ट्रैवल डिबगिंग एक पूर्ण निष्पादन ट्रेस को रिकॉर्ड करता है जो डिबगर को निष्पादन इतिहास के माध्यम से पीछे और साथ ही आगे बढ़ने की इजाजत देता है - उन बगों के लिए सबसे फायदेमंद जहां विफलता बिंदु कारण दोष से बहुत दूर है (भ्रष्टाचार चरण 1 पर होता है, चरण 10000 पर दुर्घटना)
C
Time-travel debugging is only available for JavaScript applications running in Chrome DevTools टाइम-ट्रैवल डिबगिंग केवल Chrome DevTools में चल रहे जावास्क्रिप्ट अनुप्रयोगों के लिए उपलब्ध है
D
Time-travel debugging requires specialised hardware and is not available for software-only systems टाइम-ट्रैवल डिबगिंग के लिए विशेष हार्डवेयर की आवश्यकता होती है और यह केवल सॉफ़्टवेयर सिस्टम के लिए उपलब्ध नहीं है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Mozilla RR, WinDbg TTD, and UndoDB enable recording + replay with reverse stepping. Classic use: a data structure is corrupted at step 1 but the crash occurs at step 10,000. Traditional debugging: find crash, step backward manually. Time-travel: set watchpoint on the corrupted memory address and run backward — the debugger stops exactly when the corruption occurred. This eliminates one of debugging's hardest problems: tracing effects back to causes across large execution gaps.
व्याख्या (हिन्दी) मोज़िला आरआर, विनडीबीजी टीटीडी, और अनडोडीबी रिवर्स स्टेपिंग के साथ रिकॉर्डिंग + रीप्ले सक्षम करते हैं। क्लासिक उपयोग: डेटा संरचना चरण 1 पर दूषित हो जाती है लेकिन चरण 10,000 पर क्रैश हो जाती है। पारंपरिक डिबगिंग: क्रैश ढूंढें, मैन्युअल रूप से पीछे की ओर कदम बढ़ाएं। समय-यात्रा: दूषित मेमोरी पते पर वॉचपॉइंट सेट करें और पीछे की ओर चलाएं - भ्रष्टाचार होने पर डिबगर ठीक से बंद हो जाता है। यह डिबगिंग की सबसे कठिन समस्याओं में से एक को समाप्त करता है: बड़े निष्पादन अंतरालों के कारण प्रभावों का पता लगाना।
209
EN + हिं Easy
GB What is the 'scientific method' applied to debugging and what specific cognitive error does it prevent?
IN डिबगिंग के लिए प्रयुक्त 'वैज्ञानिक विधि' क्या है और यह किस विशिष्ट संज्ञानात्मक त्रुटि को रोकती है?
A
Scientific method debugging requires formal mathematical proofs of every hypothesised fix वैज्ञानिक विधि डिबगिंग के लिए प्रत्येक परिकल्पित समाधान के औपचारिक गणितीय प्रमाण की आवश्यकता होती है
B
Scientific debugging forms explicit hypotheses, designs a minimal experiment to test each hypothesis, and records results before forming the next — preventing 'shotgun debugging' (making random changes hoping one fixes the bug) which destroys evidence and may mask the real fault वैज्ञानिक डिबगिंग स्पष्ट परिकल्पनाएँ बनाती है, प्रत्येक परिकल्पना का परीक्षण करने के लिए एक न्यूनतम प्रयोग डिज़ाइन करती है, और अगली परिकल्पना बनाने से पहले परिणामों को रिकॉर्ड करती है - 'शॉटगन डिबगिंग' को रोकना (इस उम्मीद में यादृच्छिक परिवर्तन करना कि कोई बग को ठीक कर देगा) जो साक्ष्य को नष्ट कर देता है और वास्तविक गलती को छिपा सकता है
C
Scientific method debugging is only taught in academic computer science courses and not used in industry वैज्ञानिक विधि डिबगिंग केवल अकादमिक कंप्यूटर विज्ञान पाठ्यक्रमों में पढ़ाई जाती है और उद्योग में इसका उपयोग नहीं किया जाता है
D
Scientific debugging requires more time than shotgun debugging and is only used for critical bugs वैज्ञानिक डिबगिंग के लिए शॉटगन डिबगिंग की तुलना में अधिक समय की आवश्यकता होती है और इसका उपयोग केवल गंभीर बग के लिए किया जाता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Shotgun debugging: change everything at once and see if it works — this may fix the symptom while leaving the cause intact, or fix by luck while masking a related defect. Scientific debugging: 'My hypothesis: the bug is caused by X. I'll change only X and observe. Result: still broken. New hypothesis: Y.' Each experiment is minimal and isolated, preserving evidence and systematically narrowing the fault location.
व्याख्या (हिन्दी) शॉटगन डिबगिंग: सब कुछ एक बार में बदलें और देखें कि क्या यह काम करता है - यह कारण को बरकरार रखते हुए लक्षण को ठीक कर सकता है, या संबंधित दोष को छिपाते हुए भाग्य से ठीक कर सकता है। वैज्ञानिक डिबगिंग: 'मेरी परिकल्पना: बग एक्स के कारण होता है। मैं केवल एक्स को बदलूंगा और निरीक्षण करूंगा। नतीजा: अभी भी टूटा हुआ. नई परिकल्पना: वाई.' प्रत्येक प्रयोग न्यूनतम और पृथक है, साक्ष्य को संरक्षित करता है और गलती के स्थान को व्यवस्थित रूप से सीमित करता है।
210
EN + हिं Easy
GB What is 'logging correlation ID' pattern in microservices debugging and what distributed tracing problem does it solve?
IN माइक्रोसर्विसेज डिबगिंग में 'लॉगिंग सहसंबंध आईडी' पैटर्न क्या है और यह किस वितरित ट्रेसिंग समस्या का समाधान करता है?
A
Correlation IDs are database primary keys used to track records across multiple tables सहसंबंध आईडी डेटाबेस प्राथमिक कुंजी हैं जिनका उपयोग कई तालिकाओं में रिकॉर्ड को ट्रैक करने के लिए किया जाता है
B
A correlation ID is a unique identifier generated at request entry and propagated through all service calls — solving the problem of matching log entries from Service A, B, C, and D that all processed the same user request across thousands of concurrent requests सहसंबंध आईडी एक अद्वितीय पहचानकर्ता है जो अनुरोध प्रविष्टि पर उत्पन्न होता है और सभी सेवा कॉल के माध्यम से प्रचारित होता है - सेवा ए, बी, सी और डी से मिलान लॉग प्रविष्टियों की समस्या को हल करता है जो सभी हजारों समवर्ती अनुरोधों में एक ही उपयोगकर्ता अनुरोध को संसाधित करते हैं
C
Correlation IDs are only needed when services are deployed in different cloud regions सहसंबंध आईडी की आवश्यकता केवल तभी होती है जब सेवाएँ विभिन्न क्लाउड क्षेत्रों में तैनात की जाती हैं
D
Correlation IDs are automatically added by all cloud load balancers and require no developer action सहसंबंध आईडी सभी क्लाउड लोड बैलेंसर्स द्वारा स्वचालित रूप से जोड़े जाते हैं और किसी डेवलपर कार्रवाई की आवश्यकता नहीं होती है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Without correlation IDs, microservice logs look like: '[10:00:01] Service A: processing request' and '[10:00:01] Service C: database error' — which request triggered the DB error? With correlation ID 'req-7f3a': '[10:00:01][req-7f3a] Service A: processing' and '[10:00:01][req-7f3a] Service C: database error' — you can filter all logs for req-7f3a to see the complete request journey. OpenTelemetry standardises this propagation.
व्याख्या (हिन्दी) सहसंबंध आईडी के बिना, माइक्रोसर्विस लॉग इस तरह दिखते हैं: '[10:00:01] सेवा ए: प्रसंस्करण अनुरोध' और '[10:00:01] सेवा सी: डेटाबेस त्रुटि' - किस अनुरोध ने डीबी त्रुटि को ट्रिगर किया? सहसंबंध आईडी 'req-7f3a' के साथ: '[10:00:01][req-7f3a] सेवा A: प्रसंस्करण' और '[10:00:01][req-7f3a] सेवा C: डेटाबेस त्रुटि' - आप संपूर्ण अनुरोध यात्रा देखने के लिए req-7f3a के लिए सभी लॉग फ़िल्टर कर सकते हैं। ओपनटेलीमेट्री इस प्रसार को मानकीकृत करती है।
196–210 of 230