एक schrödinbug क्या है?

52

एक श्रोडिनबग एक बग है जो केवल किसी स्रोत कोड को पढ़ने या किसी असामान्य तरीके से कार्यक्रम का उपयोग करने के बाद प्रकट होता है, जिसे कभी भी पहली जगह पर काम नहीं करना चाहिए, जिस बिंदु पर कार्यक्रम तुरंत तय होने तक हर किसी के लिए काम करना बंद कर देता है। शब्दजाल फ़ाइल में कहा गया है: "हालांकि ... यह असंभव लगता है, ऐसा होता है; कुछ कार्यक्रमों ने वर्षों तक अव्यक्त श्रोडोग्स को परेशान किया है।"

क्या बात की जा रही है बहुत अस्पष्ट है ..

क्या कोई उदाहरण दे सकता है कि एक श्रोडबग कैसा है (जैसे काल्पनिक / वास्तविक जीवन की स्थिति के साथ)?

bug

— Pacerier
स्रोत

15

ध्यान दें कि उद्धरण मजाक में कहा गया है।

11

मुझे लगता है कि अगर आप श्रोडिंगर की बिल्ली के बारे में जानते थे तो आप श्रोडिनबग को बेहतर समझेंगे: en.wikipedia.org/wiki/Shrodingers_cat

— Eimantas

1

@Eimantas मैं वास्तव में अब और अधिक भ्रमित हूँ लेकिन यह एक दिलचस्प लेख है :)

82

मेरे अनुभव में पैटर्न यह है:

सिस्टम काम करता है, अक्सर वर्षों के लिए
कोई त्रुटि बताई गई है
डेवलपर त्रुटि की जांच करता है और थोड़ा सा कोड पाता है जो पूरी तरह से त्रुटिपूर्ण लगता है और घोषणा करता है कि यह "कभी काम नहीं कर सकता था"
बग ठीक हो जाता है और उस कोड की किंवदंती जो कभी काम नहीं कर सकती थी (लेकिन सालों तक) बढ़ती रहती है

यहां तार्किक होना चाहिए। कोड जो कभी काम नहीं कर सकता था ... कभी काम नहीं कर सकता था । यदि यह किया काम तो बयान गलत है।

तो मैं यह कहने जा रहा हूं कि एक बग जैसा कि वर्णन किया गया है (जो त्रुटिपूर्ण कोड देख रहा है कि यह काम करना बंद कर देता है) वर्तमान में बकवास है।

वास्तव में जो हुआ है वह दो चीजों में से एक है:

1) डेवलपर ने कोड को पूरी तरह से नहीं समझा है । इस मामले में कोड आमतौर पर एक गड़बड़ है और कहीं न कहीं इसमें कुछ बाहरी स्थिति के लिए एक प्रमुख लेकिन गैर-स्पष्ट संवेदनशीलता है (एक विशिष्ट ओएस संस्करण या कॉन्फ़िगरेशन का कहना है कि यह नियंत्रित करता है कि कुछ फ़ंक्शन कुछ मामूली लेकिन महत्वपूर्ण तरीके से कैसे काम करता है)। इस बाहरी स्थिति को बदल दिया जाता है (सर्वर अपग्रेड या परिवर्तन जिसे असंबंधित माना जाता है) के अनुसार और ऐसा करने से कोड टूट जाता है।

डेवलपर तब कोड को देखता है और ऐतिहासिक संदर्भ को समझने या हर संभव निर्भरता और परिदृश्य के माध्यम से ट्रेस करने का समय नहीं है, यह घोषणा करता है कि यह कभी भी काम नहीं कर सकता था और इसे फिर से लिखता है।

इस स्थिति में, यहाँ समझने वाली बात यह है कि यह विचार कि "यह कभी भी काम नहीं कर सकता था" (यह किया गया) गलत है।

यह नहीं कहना है कि यह फिर से लिखना एक बुरी बात है - यह अक्सर नहीं होता है, जबकि यह जानना अच्छा है कि वास्तव में क्या गलत था अक्सर समय लगता है और कोड के खंड को फिर से लिखना अक्सर तेज होता है और आपको यह सुनिश्चित करने की अनुमति देता है कि आपने निश्चित चीजें तय की हैं।

2) वास्तव में इसने कभी काम नहीं किया, बस किसी ने कभी गौर नहीं किया । यह आश्चर्यजनक रूप से सामान्य है, विशेष रूप से बड़ी प्रणालियों में। इस उदाहरण में कोई नया शुरू करता है और चीजों को उस तरह से देखना शुरू करता है जैसा पहले किसी ने नहीं किया था, या एक व्यवसाय प्रक्रिया कुछ पूर्व मामूली बढ़त मामले को मुख्य प्रक्रिया में लाती है, और कुछ ऐसा जो वास्तव में कभी काम नहीं किया (या कुछ काम किया है, लेकिन सभी नहीं समय) पाया और रिपोर्ट किया गया है।

डेवलपर इसे देखता है और घोषणा करता है कि "यह कभी काम नहीं कर सकता था" लेकिन उपयोगकर्ताओं का कहना है "बकवास, हम इसे वर्षों से उपयोग कर रहे हैं" और वे सही प्रकार के हैं, लेकिन कुछ वे अप्रासंगिक मानते हैं (और आमतौर पर जब तक उल्लेख करना विफल होता है। डेवलपर सटीक स्थिति है जो बिंदु पर वे जाना "अरे हाँ, हम क्या करते हो पाता है कि अब और नहीं से पहले किया था" बदल गया है)।

यहां डेवलपर सही है - यह कभी काम नहीं कर सकता था और कभी काम नहीं करता था।

लेकिन या तो मामले में दो चीजों में से एक सच है:

यह दावा "यह कभी काम नहीं कर सकता था" सच है और इसने कभी काम नहीं किया है - लोगों ने सिर्फ सोचा था कि यह किया
इसने काम किया और कथन "यह कभी काम नहीं कर सकता था" कोड और उसकी दक्षता को समझने के लिए गलत और एक (आमतौर पर उचित) कमी है।

— जॉन हॉपकिंस
स्रोत

1

इतनी बार मेरे लिए होता है

— उत्पत्ति

2

यथार्थवाद में इन स्थितियों के बारे में महान अंतर्दृष्टि

— स्टुपरयूजर

1

मुझे लगता है कि यह आमतौर पर एक "डब्ल्यूटीएफ" पल का परिणाम होता है। मेरे पास एक बार था। मैंने अपने द्वारा लिखे गए कुछ कोड को दोबारा पढ़ा और महसूस किया कि एक बग जिसे हाल ही में देखा गया था, जिससे पूरा ऐप टूट जाना चाहिए था। दरअसल, आगे के निरीक्षण के बाद, मैंने जो एक और घटक लिखा था वह इतना अच्छा था कि उसने गलतियों की भरपाई की।

— थाडी टाइ

1

@ थड्डी - मैंने देखा है कि पहले, लेकिन मैंने कोड मॉड्यूल में दो बग भी देखे हैं जो एक दूसरे को एक दूसरे को रद्द करने के लिए कहते हैं इसलिए यह वास्तव में काम करता है। एक को देखो और वे टूट गए लेकिन साथ में वे ठीक थे।

— जॉन हॉपकिंस

7

@ जौन हॉपकिंस: मुझे 2 बग्स का एक-दूसरे को रद्द करने का मामला भी मिला, और यह वास्तव में आश्चर्यजनक है। मुझे एक बग मिला, जो कुख्यात बयान "यह कभी काम नहीं कर सकता" का मुंह ताक रहा था, यह जानने के लिए गहराई से देखा कि यह किसी भी तरह क्यों काम करता है, और एक और बग पाया जो पहले वाले को सही करता था, अधिकांश मामलों में कम से कम। मैं वास्तव में इस खोज से स्तब्ध था, और इस तथ्य से कि केवल एक बग के साथ, परिणाम भयावह होगा!

— एलेक्सिस डुफ्रेनॉय

54

क्योंकि सभी में उस कोड का उल्लेख है जिसे कभी काम नहीं करना चाहिए था, मैं आपको एक उदाहरण दूंगा जिसमें मैं भाग गया था, लगभग 8 साल पहले एक मरने वाले VB3 प्रोजेक्ट पर जो कि .net में परिवर्तित हो रहा था। दुर्भाग्यवश .net संस्करण पूरा होने तक परियोजना को अप-टू-डेट रखा जाना था - और मैं केवल वही था जो दूरस्थ रूप से VB3 को भी समझता था।

एक बहुत महत्वपूर्ण कार्य था जिसे प्रत्येक गणना के लिए सैकड़ों बार कहा जाता था - यह दीर्घकालिक पेंशन योजनाओं के लिए मासिक ब्याज की गणना करता था। मैं दिलचस्प भागों को पुन: पेश करता हूँ।

Function CalculateMonthlyInterest([...], IsYearlyInterestMode As Boolean, [...]) As Double
    [about 30 lines of code]
    If IsYearlyInterestMode Then
        [about 30 lines of code]
        If Not IsYearlyInterestMode Then
            [about 30 lines of code (*)]
        End If
    End If
End Function

एक स्टार के साथ चिह्नित भाग में सबसे महत्वपूर्ण कोड था; यह एकमात्र भाग था जिसने वास्तविक गणना की। स्पष्ट रूप से यह कभी भी काम नहीं करना चाहिए, है ना?

इस पर बहुत डिबगिंग हुई, लेकिन मुझे अंततः इसका कारण मिला: यह सच IsYearlyInterestModeथा True, और Not IsYearlyInterestModeसच भी था। ऐसा इसलिए है क्योंकि कहीं न कहीं लाइन के साथ किसी ने इसे एक पूर्णांक में डाल दिया है, तो एक फ़ंक्शन में जिसे इसे वास्तविक वृद्धि के लिए सेट करना है (यदि यह 0 है तो इसे False1 पर सेट किया जाएगा, जो कि VB है True, इसलिए मैं तर्क देख सकता हूं वहाँ), फिर इसे एक बूलियन में वापस डाल दिया। और मुझे एक शर्त के साथ छोड़ दिया गया था जो कभी नहीं हो सकता है और फिर भी हर समय होता है।

— विन्यासक
स्रोत

7

उपसंहार: मैंने कभी उस कार्य को तय नहीं किया; मैंने सिर्फ अन्य लोगों की तरह 2 को भेजने में विफल कॉल साइट को पैच किया।

— विन्यासकर्ता

तो आपका मतलब है कि यह तब उपयोग किया जाता है जब लोग कोड को गलत बताते हैं?

— पचेरियर

1

@ स्पेसर: अधिक बार जब कोड एक ऐसी गड़बड़ी है कि यह केवल दुर्घटना से सही ढंग से काम करता है। मेरे उदाहरण में, कोई भी डेवलपर IsYearlyInterestModeसही और सही दोनों के रूप में मूल्यांकन करने के लिए नहीं था; मूल डेवलपर जिसने कुछ पंक्तियों को जोड़ा (जिनमें से एक ifएस वास्तव में यह कैसे काम करता है, यह समझ में नहीं आया - यह सिर्फ काम करने के लिए हुआ था इसलिए यह काफी अच्छा था।

— विन्यासकर्ता

16

एक वास्तविक दुनिया का उदाहरण नहीं जानते, लेकिन एक उदाहरण की स्थिति के साथ इसे सरल बनाने के लिए:

बग पर एक समय के लिए ध्यान नहीं दिया जाता है, क्योंकि एप्लिकेशन उन परिस्थितियों में कोड नहीं चलाता है जो इसे विफल करते हैं।
कोई व्यक्ति सामान्य उपयोग के बाहर कुछ करके (या स्रोत का निरीक्षण करके) इसे नोटिस करता है।
अब जब बग पर ध्यान दिया जाता है, तो आवेदन सामान्य परिस्थितियों के साथ-साथ बग के ठीक होने तक विफल रहता है।

ऐसा इसलिए हो सकता है क्योंकि बग एप्लिकेशन के कुछ राज्य को दूषित कर देगा जो पहले की सामान्य परिस्थितियों में विफलताओं का कारण बनते हैं।

— StuperUser
स्रोत

4

एक व्याख्या यह है कि सॉफ्टवेयर में बेतरतीब विफलताएं थीं, कोई भी मानसिक रूप से एक साथ जुड़ने में सक्षम नहीं था। इस प्रकार, उन त्रुटियों को प्राकृतिक कारण माना जाता था (जैसे कि यादृच्छिक हार्डवेयर विफलताएं)। एक बार स्रोत कोड पढ़ने के बाद, लोग अब इस एक कारण से सभी पूर्व यादृच्छिक त्रुटियों से संबंधित हो सकते हैं, और यह महसूस करेंगे कि इसे पहले स्थान पर काम नहीं करना चाहिए।

— रॉव

4

एक दूसरा स्पष्टीकरण यह है कि सॉफ्टवेयर में एक हिस्सा है जिसे चेन-ऑफ-जिम्मेदारी पैटर्न के साथ लागू किया गया है। प्रत्येक हैंडलर को एक मजबूत तरीके से लिखा गया है, इसके बावजूद एक हैंडलर के पास एक महत्वपूर्ण बग है। अब, पहला हैंडलर हमेशा विफल हो जाएगा, लेकिन दूसरे हैंडलर (जो जिम्मेदारी में ओवरलैप हो गया है) के कारण एक ही कार्य को पूरा करने की कोशिश करता है, कुल मिलाकर ऑपरेशन सफल हुआ होगा। यदि दूसरे मॉड्यूल में कोई परिवर्तन होता है, जैसे कि जिम्मेदारी क्षेत्र में परिवर्तन, तो यह एक समग्र विफलता का कारण होगा, हालांकि असली बग एक अलग स्थान पर है।

— जुआन

13

एक वास्तविक जीवन का उदाहरण। मैं कोड नहीं दिखा सकता, लेकिन ज्यादातर लोग इससे संबंधित होंगे।

हमारे पास उपयोगिता कार्यों का एक बड़ा आंतरिक पुस्तकालय है जहां मैं काम करता हूं। एक दिन मैं किसी विशेष कार्य को करने के लिए एक समारोह की तलाश कर रहा हूं, और मुझे Frobnicate()इसका उपयोग करने का प्रयास मिल रहा है। उह-ओह: यह पता चला है कि Frobnicate()हमेशा एक त्रुटि कोड देता है।

कार्यान्वयन में खुदाई करने पर, मुझे इसमें कुछ बुनियादी तर्क त्रुटियां मिलीं, Frobnicate()जो इसे हमेशा विफल बनाती हैं। स्रोत नियंत्रण में मैं देख सकता हूं कि फ़ंक्शन को संशोधित नहीं किया गया है क्योंकि यह लिखा गया था, जिसका अर्थ है कि फ़ंक्शन ने कभी भी काम नहीं किया है। किसी ने इस पर ध्यान क्यों नहीं दिया? मैं शेष स्रोत सूची के माध्यम से खोजता हूं और पाता हूं कि सभी मौजूदा कॉलर्स Frobnicate()रिटर्न वैल्यू को नजरअंदाज कर रहे हैं (और इसलिए उनके अपने सूक्ष्म कीड़े हैं)। यदि मैं उन कार्यों को बदले मूल्य की जांच करने के लिए बदल देता हूं, तो उन्हें असफल होना शुरू हो जाता है।

यह शर्त # 2 का एक सामान्य मामला है जो जॉन हॉपकिंस ने अपने उत्तर में उल्लेख किया है, और यह बड़े आंतरिक पुस्तकालयों में निराशाजनक रूप से आम है।

— JSB ձոգչ
स्रोत

... जो आंतरिक पुस्तकालय लिखने से बचने का एक अच्छा कारण है, जहां कोई बाहरी प्रयोग करने योग्य है। इसका अधिक परीक्षण किया जाएगा और इस प्रकार ऐसे कम आश्चर्यजनक आश्चर्य होंगे (ओपन-सोर्स लाइब्रेरी बेहतर हैं, क्योंकि आप उन्हें ठीक कर सकते हैं यदि वे वैसे भी करते हैं)।

— जन हुदेक

हाँ, लेकिन अगर प्रोग्रामर रिटर्न कोड को अनदेखा करते हैं जो लाइब्रेरी की गलती नहीं है। (वैसे, आखिरी बार जब आपने रेटकोड की जाँच की थी printf()?)

— जेन्सजी

यही कारण है कि जाँच किए गए अपवादों का आविष्कार किया गया था।

— केविन क्रुमविडे

10

यहाँ एक वास्तविक श्रोडीनबग है जिसे मैंने कुछ सिस्टम कोड में देखा था। एक रूट डेमॉन को एक कर्नेल मॉड्यूल के साथ संवाद करने की आवश्यकता होती है। तो कर्नेल कोड कुछ फ़ाइल डिस्क्रिप्टर बनाता है:

int pipeFDs[1];

फिर एक पाइप पर संचार स्थापित करता है जिसे एक नामित पाइप से जोड़ा जाएगा:

int pipeResult = pipe(pipeFDs);

यह काम नहीं करना चाहिए । pipe()सरणी में दो फ़ाइल डिस्क्रिप्टर लिखते हैं, लेकिन एक के लिए केवल स्थान है। लेकिन के बारे में सात साल के लिए यह किया था काम; सरणी स्मृति में कुछ अप्रयुक्त स्थान से पहले हुई थी जो एक फाइल डिस्क्रिप्टर होने के कारण कोप्टेड हो गई थी।

फिर, एक दिन, मुझे एक नई वास्तुकला के लिए कोड को पोर्ट करना पड़ा। इसने काम करना बंद कर दिया, और बग को कभी भी काम नहीं करना चाहिए था।

5

श्रोडीनबग का एक कोरोल हेइज़ेनबग है - जो एक बग का वर्णन करता है जो गायब हो जाता है (या कभी-कभी प्रकट होता है) जब जांच और / या इसे ठीक करने का प्रयास किया जाता है।

हाइजेनबग्स एक चतुर चालाक छोटे ब्लेटर हैं जो एक डिबगर लोड होने पर भागते हैं और छुपते हैं, लेकिन एक बार जब आप देखना बंद कर देते हैं तो लकड़ी से बाहर आ जाते हैं।

वास्तव में, ये आमतौर पर निम्नलिखित में से एक या अन्य के कारण होते हैं:

ऑप्टिमाइज़ेशन का प्रभाव, जहाँ कोड के साथ संकलित किया -DDEBUGगया रिलीज़ रिलीज़ बिल्ड से भिन्न स्तर पर अनुकूलित होता है
वास्तविक-समय की संचार बसों के कारण सूक्ष्म समय का अंतर या सिम्युलेटेड "संपूर्ण" डमी लोड से सूक्ष्म रूप से भिन्न होना

दोनों रिलीज उपकरणों पर परीक्षण रिलीज कोड के महत्व पर प्रकाश डालते हैं, साथ ही एमुलेटर का उपयोग करके यूनिट / मॉड्यूल / सिस्टम टेस्ट करते हैं।

— एंड्रयू
स्रोत

मैंने यह पोस्ट करने से पहले S.Lote के उत्तर और डेलान की टिप्पणी पर ध्यान क्यों नहीं दिया?

— एंड्रयू

मैंने बहुत कम अनुभव किया है लेकिन मुझे इसमें से कुछ मिला है। मैं एक Android NDK वातावरण में काम कर रहा था। जब डीबगर ने एक ब्रेकपॉइंट पाया तो यह केवल जावा थ्रेड्स को बंद कर दिया, न कि सी ++ वाले, कुछ कॉल को संभव बना दिया क्योंकि तत्वों को सी ++ पर आरंभीकृत किया गया था। यदि डिबगर के बिना छोड़ा जाता है, तो जावा कोड C ++ की तुलना में तेजी से आगे बढ़ेगा और उन मूल्यों का उपयोग करने की कोशिश करेगा जो अभी तक आरंभ नहीं किए गए थे।

— MLProgrammer-CiM

मैंने कुछ महीने पहले Django डेटाबेस API के उपयोग में एक हेइज़ेनबग की खोज की थी: जब DEBUG = True, "पैरामीटर" का नाम एक कच्चे SQL क्वेरी परिवर्तनों के लिए आता है। हम क्वेरी की लंबाई के कारण स्पष्टता के लिए एक कीवर्ड आर्ग के रूप में इसका उपयोग कर रहे थे, जो पूरी तरह से टूट गया जब यह बीटा साइट पर धकेलने का समय था, जहांDEBUG = False

— इजाका

2

मैंने कुछ Schödinbugs और हमेशा एक ही कारण के लिए देखा है:

कंपनी की नीति के लिए आवश्यक था कि हर कोई एक कार्यक्रम का उपयोग करे।
किसी ने वास्तव में इसका इस्तेमाल नहीं किया (ज्यादातर इसलिए कि इसके लिए कोई प्रशिक्षण नहीं था।)
लेकिन वे प्रबंधन को यह नहीं बता सके। तो हर किसी को कहना था "मैं 2 साल से इस कार्यक्रम का उपयोग कर रहा हूं और आज तक इस बग का कभी सामना नहीं किया।"
प्रोग्राम ने वास्तव में कभी काम नहीं किया, सिवाय उपयोगकर्ताओं की अल्पमत के (इसे लिखने वाले डेवलपर्स सहित)।

एक मामले में, कार्यक्रम बहुत परीक्षण के अधीन था, लेकिन वास्तविक डेटाबेस पर नहीं (जिसे बहुत संवेदनशील माना गया था, इसलिए एक नकली संस्करण का उपयोग किया गया था।)

— finnw
स्रोत

1

मेरे पास अपने इतिहास से एक उदाहरण है, यह कुछ 25 साल पहले था। मैं टर्बो पास्कल में अल्पविकसित ग्राफिक्स प्रोग्रामिंग करने वाला बच्चा था। टीपी के पास बीजीआई नामक एक पुस्तकालय था जिसमें कुछ कार्य शामिल थे जो आपको स्क्रीन के एक क्षेत्र को एक सूचक-आधारित मेमोरी-ब्लॉक में कॉपी करते हैं, और फिर इसे कहीं और ब्लिट करते हैं। एक ब्लैक-एंड-व्हाइट-स्क्रीन पर एक्स-ब्लिटिंग के साथ संयुक्त यह सरल एनीमेशन करने के लिए इस्तेमाल किया जा सकता है।

मैं इसे एक कदम और आगे ले जाना चाहता था और स्प्राइट बनाना चाहता था। मैंने एक प्रोग्राम लिखा, जिसमें बड़े-बड़े ब्लॉक और कंट्रोल किए गए ताकि उन्हें रंग दिया जा सके, क्योंकि आपने ऐसा किया था कि उन्हें पिक्सेल के रूप में पुन: पेश किया गया, स्प्राइट बनाने के लिए एक साधारण ड्राइंग प्रोग्राम का निर्माण किया, जिसे वह फिर मेमोरी में कॉपी कर सकता था। बस एक समस्या थी, इन धुंधले स्प्राइट्स का उपयोग करने के लिए, उन्हें एक फाइल में सहेजना होगा ताकि अन्य प्रोग्राम उन्हें पढ़ सकें। लेकिन टीपी के पास सूचक आधारित मेमोरी आवंटन को क्रमबद्ध करने का कोई तरीका नहीं था। जिन फ्लैटों का उल्लेख किया गया है, वे फ़ाइल में लिखे नहीं जा सकते हैं।

मैं कोड का एक टुकड़ा लेकर आया, जिसने सफलतापूर्वक, फाइल करने के लिए लिखा। और एक परीक्षण कार्यक्रम लिखना शुरू कर दिया जिसने एक पृष्ठभूमि पर मेरे ड्राइंग प्रोग्राम से एक प्रेत को उड़ा दिया - एक खेल बनाने के लिए मेरे रास्ते पर। और यह काम किया, खूबसूरती से। हालांकि अगले दिन, इसने काम करना बंद कर दिया। यह एक गड़बड़ गड़बड़ के अलावा कुछ भी नहीं दिखाया। इसने फिर कभी काम नहीं किया। मैंने एक नया स्प्राइट बनाया, और यह पूरी तरह से काम किया - जब तक कि यह नहीं हुआ, और यह फिर से एक गड़बड़ गड़बड़ था।

इसमें लंबा समय लगा लेकिन आखिरकार मुझे पता चला कि क्या हो रहा है। ड्राइंग प्रोग्राम नहीं था, जैसा कि मैंने सोचा था, कॉपी किए गए पिक्सेल डेटा को फ़ाइल करने के लिए सहेज रहा है - यह सूचक को ही बचा रहा था। जब अगले कार्यक्रम ने फ़ाइल को पढ़ा, तो यह एक पॉइंटर के साथ मेमोरी के उसी ब्लॉक तक समाप्त हो गया - जिसमें अभी भी वही था जो आखिरी प्रोग्राम वहां लिखा था (यह एमएस-डॉस पर था, मेमोरी मैनेजमेंट न के बराबर था)। लेकिन यह काम किया ... ठीक है जब तक आपने रिबूट नहीं किया, या कुछ भी चलाया था, जो स्मृति के उसी क्षेत्र को पुन: उपयोग किया था, और फिर आपको एक गड़बड़ गड़बड़ मिल गई क्योंकि आप वीडियो-मेमोरी ब्लॉक में पूरी तरह से असंबंधित डेटा का एक गुच्छा ब्लिट कर रहे थे।

इसे कभी काम नहीं करना चाहिए था, इसे कभी भी काम नहीं करना चाहिए था (और किसी भी वास्तविक ओएस पर यह नहीं होगा) लेकिन यह अभी भी किया था, और एक बार यह टूट गया - यह टूटा रहा।

— silentcoder
स्रोत

0

यह हर समय होता है जब लोग डीबगर का उपयोग करते हैं।

डिबगिंग वातावरण वास्तविक - कोई डीबगर - उत्पादन वातावरण से भिन्न होता है।

डिबगर के साथ चलने से स्टैक ओवरफ्लो जैसी चीजों को मास्क किया जा सकता है क्योंकि डीबगर के स्टैक फ्रेम बग को मास्क करते हैं।

— S.Lott
स्रोत

मुझे नहीं लगता कि यह डिबगर में चल रहे कोड और संकलित होने के बीच के अंतर का जिक्र है।

— जॉन हॉपकिंस

26

यही कारण है कि एक schrödinbug नहीं है, कि एक है heisenbug ।

@ डेलन: यह आइएमओ के किनारे पर है। मुझे यह एक अनिश्चित बात लगती है क्योंकि आजादी के अनजाने अंश हैं। मैं उन चीज़ों के लिए हेइज़ेनबग को आरक्षित करना पसंद करता हूं जहां एक चीज़ को मापना वास्तव में दूसरे को परेशान करता है (यानी, दौड़ की स्थिति, अनुकूलक सेटिंग्स, नेटवर्क बैंडविड्थ सीमाएं, आदि)

— S.Lott

@ एस.लॉट: आपके द्वारा वर्णित स्थिति स्टैक फ्रेम या जैसे के साथ गड़बड़ करके अवलोकन बदलती चीजों को शामिल करती है। (सबसे खराब ऐसा उदाहरण जो मैंने कभी देखा था कि डीबगर शांतिपूर्ण तरीके से और "सही ढंग से" एकल-स्टेप मोड में अमान्य सेगमेंट रजिस्टर मानों के भार को निष्पादित करेगा। परिणाम RTL में कुछ रूटीन थे जो संरक्षित मोड में रहते हुए एक वास्तविक मोड पॉइंटर लोड करने के बावजूद भेज दिया गया था। । चूंकि यह केवल नकल की और नहीं किया जा रहा था dereferenced यह पूरी तरह से व्यवहार)।

— लोरेन Pechtel

0

मैंने कभी भी एक सच्चा विद्वान नहीं देखा है और मुझे नहीं लगता कि वे मौजूद हो सकते हैं - यह पता लगाने से चीजें नहीं टूटेंगी।

बल्कि, कुछ ऐसा बदला जिसने एक बग को उजागर किया जो युगों से दुबका रहा है। जो कुछ भी बदला है वह अभी भी बदला हुआ है और इस प्रकार बग दिखाई देता रहता है जबकि उसी समय कोई बग ढूंढता है।

— लोरेन Pechtel
स्रोत