आपका सबसे कठिन बग शिकार क्या था और आपने इसे कैसे पाया और इसे मार डाला?


31

यह एक "ज्ञान साझा करें" प्रश्न है। मुझे आपकी सफलताओं और / या असफलताओं से सीखने में दिलचस्पी है।

जानकारी जो सहायक हो सकती है ...

पृष्ठभूमि:

  • संदर्भ: भाषा, अनुप्रयोग, पर्यावरण, आदि।
  • बग की पहचान कैसे हुई?
  • बग की पहचान किसने या किससे की?
  • बग को पुन: पेश करना कितना जटिल था?

शिकार।

  • आपकी योजना क्या थी?
  • आपको किन कठिनाइयों का सामना करना पड़ा?
  • आपत्तिजनक कोड आखिर कैसे पाया गया?

मारना।

  • फिक्स कितना जटिल था?
  • आपने फिक्स का दायरा कैसे तय किया?
  • फिक्स में कितना कोड शामिल था?

शवपरीक्षा।

  • तकनीकी रूप से मूल कारण क्या था? बफर ओवररन, आदि।
  • 30,000 फीट से मूल कारण क्या था?
  • आखिरकार प्रक्रिया में कितना समय लगा?
  • क्या फिक्स द्वारा प्रतिकूल रूप से प्रभावित कोई विशेषता थी?
  • क्या तरीके, उपकरण, प्रेरणाएँ आपको विशेष रूप से उपयोगी लगीं? ... बुरी तरह से बेकार?
  • यदि आप यह सब फिर से कर सके तो? ...........

ये उदाहरण सामान्य हैं, हर स्थिति में लागू नहीं होते हैं और संभवतः बेकार हैं। कृपया आवश्यकतानुसार मौसम।

जवाबों:


71

यह वास्तव में हमारे आवेदन के तीसरे पक्ष के छवि दर्शक उप-घटक में था।

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

हमने सामान्य चरणों की कोशिश की:

(१) उन्हें कंप्यूटर को किसी अन्य उपयोगकर्ता के साथ स्विच करना था जिन्हें कभी भी कंप्यूटर / कॉन्फ़िगरेशन को नियमबद्ध करने की समस्या नहीं थी। - समस्या ने उनका पीछा किया।

(2) उन्हें एप्लिकेशन में लॉग इन किया और एक ऐसे उपयोगकर्ता के रूप में काम किया जिसने कभी समस्या नहीं देखी। - STILL समस्या ने उनका अनुसरण किया।

(3) उपयोगकर्ता की रिपोर्ट थी कि वे किस छवि को देख रहे थे और त्वरित उत्तराधिकार में उस छवि को हजारों बार देखने के लिए दोहराने के लिए एक परीक्षण दोहन स्थापित किया। समस्या स्वयं को प्रस्तुत करने में नहीं थी।

(४) एक डेवलपर उपयोगकर्ताओं के साथ बैठकर उन्हें पूरे दिन देखता था। उन्होंने त्रुटियां देखीं, लेकिन उन्हें नोटिस नहीं किया कि वे कुछ भी कर सकते हैं, जिससे उन्हें नुकसान हो।

हम हफ्तों तक इस बात से जूझते रहे कि "त्रुटि उपयोगकर्ताओं" में यह जानने की कोशिश की गई कि अन्य उपयोगकर्ताओं ने क्या किया। मुझे नहीं पता कि कैसे, लेकिन स्टेप (4) में डेवलपर के पास एक दिन में एनसाइक्लोपीडिया ब्राउन के योग्य काम करने के लिए ड्राइव पर एक यूरेका पल था।

उन्होंने महसूस किया कि सभी "त्रुटि उपयोगकर्ता" को छोड़ दिया गया था, और इस तथ्य की पुष्टि की। केवल बाएं हाथ के उपयोगकर्ताओं को त्रुटियां मिलीं, कभी राइटिज़ नहीं। लेकिन कैसे छोड़ा जा सकता है एक बग कारण?

हमने उसे नीचे बैठने और बाएं हाथ को फिर से देखने के लिए विशेष रूप से किसी भी चीज पर ध्यान दिया जो वे अलग तरीके से कर रहे होंगे, और यही हमने इसे पाया।

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

जाहिरा तौर पर, अगली छवि को लोड करने के लिए प्रतीक्षा करते समय, उपयोगकर्ता सभी स्वाभाविक रूप से अपने हाथ (और इस प्रकार माउस) को कीबोर्ड की ओर ले जाते हैं।

जो उपयोगकर्ता सबसे अधिक बार त्रुटि प्राप्त करता है, वह उन ADD प्रकारों में से एक था जो अनिवार्य रूप से अपने माउस को बहुत ही अधीरता से इधर-उधर घुमाता था, जबकि अगले पेज के लोड होने की प्रतीक्षा करता था, इस प्रकार वह माउस को बहुत तेजी से सही तरीके से घुमा रहा था और मार रहा था। समय सही है तो उसने ऐसा किया जब लोड घटना हुई। जब तक हमें वेंडर से फ़िक्स नहीं मिल जाता, हमने उसे सिर्फ (अगला दस्तावेज़) क्लिक करने के बाद माउस को जाने दिया और लोड होने तक उसे छूने नहीं दिया।

इसके बाद देव टीम पर "द लेफ्ट हैंडेड बग" के नाम से प्रसिद्ध हो गया


14
यह सबसे बुरी बात है जिसे मैंने कभी सुना है।
नाथन टेलर

9
यह उस व्यक्ति से बाहर एक नायक बना जिसने इसे हल किया, हालांकि।
जॉनएफएक्स

2
वाह, अब यह एक बग की बिल्ली है!
मचेल सेलर्स

3
शानदार खोज! अच्छी कहानी।
तून Krijthe

11
जैसे कि हम वामपंथी पहले से ही द्वितीय श्रेणी के नागरिकों की तरह पर्याप्त व्यवहार नहीं कर रहे हैं। अब हमें सॉफ्टवेयर बग के अपने उचित हिस्से से भी अधिक दुखी होना होगा ... जी, धन्यवाद! : पी
डैन मोल्डिंग मोल्डिंग

11

यह बहुत पहले से है (1980 के दशक के उत्तरार्ध में)।

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

संग्रहीत करते समय इकाई का प्रकार (लाइन, आर्क, टेक्स्ट आदि) 4096 से गुणा किया गया (मुझे लगता है)। इसके अलावा हटाए गए आइटम को इंगित करने के लिए इस मान को नकार दिया गया था। तो हमारे पास जो कोड था उसे टाइप करने के लिए:

type = record[1] MOD 4096

एक को छोड़कर हर मशीन पर यह ± 1 (एक लाइन के लिए), for 2 (एक आर्क के लिए) आदि दिया गया था और हम तब हटा सकते हैं यह देखने के लिए साइन की जाँच कर सकते हैं।

एक मशीन (एचपी मुझे लगता है) पर हमें एक अजीब समस्या थी जहां हटाए गए सामान की हैंडलिंग खराब हो गई थी।

यह आईडीई के और दृश्य डिबगर्स से पहले के दिनों में था इसलिए मुझे ट्रेस स्टेटमेंट्स डालने और समस्या को हल करने के लिए लॉगिंग करना पड़ा।

मुझे अंततः पता चला कि यह इसलिए था क्योंकि हर दूसरे निर्माता ने लागू किया MODथा, -4096 MOD 4096जिसके परिणामस्वरूप -1एचपी ने इसे गणितीय रूप से सही ढंग से लागू किया था, -4096 MOD 4096जिसके परिणामस्वरूप -4097

मैंने पूरे कोड बेस के माध्यम से जाने के लिए मूल्य के चिह्न को सहेजने और प्रदर्शन करने से पहले सकारात्मक बनाने MODऔर फिर परिणाम को संकेत मूल्य से गुणा करने के बाद समाप्त कर दिया ।

इसमें कई दिन लगे।


3
वहाँ शायद अधिक कठिन बग शिकार वर्षों में किया गया है, लेकिन यह एक मेरे दिमाग में 20 से अधिक वर्षों के लिए अटक गया है!
ChrisF

7

वाह, यहाँ अच्छा पढ़ना!

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

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

आखिरकार मैंने इसे एक ऐसी जगह पर सीमित कर दिया, जहां एक सबरूटीन कहा जा रहा था, 2 दिया जा रहा था, लेकिन इसके भीतर से कुछ गिबरिश नंबर देखा गया। मैं इसे पहले भी पकड़ सकता था, लेकिन इस उपप्रधान में कदम नहीं रखा था, यह मानते हुए कि इसे जो दिया गया था। चीजों को सबसे सरल मानकर अंधा कर देना ठीक था!

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

इसलिए मेरे पास व्यक्तिगत अनुभव है कि कीमत सलाहकार के बारे में एक किस्सा आता है, थोड़ी देर के बाद कहीं एक टैप करता है, और $ 2000 चार्ज करता है। अधिकारी एक टूटने की मांग करते हैं, और यह नल के लिए $ 1 है, $ 1999 को जानने के लिए कि कहां टैप करना है। मेरे मामले को छोड़कर, यह समय नहीं था।

सबक सीखा: 1) सबसे अच्छे संकलक का उपयोग करते हैं, जहां "सर्वश्रेष्ठ" को परिभाषित किया जाता है, जिसमें कई समस्याओं के लिए कंप्यूटर विज्ञान की जांच करना भी शामिल है, और 2) सरल स्पष्ट चीजों पर सवाल उठाते हैं, या कम से कम उनके उचित कामकाज को सत्यापित करते हैं।

तब से सभी कठिन कीड़े वास्तव में कठिन हो गए हैं, जैसा कि मैं जानता हूं कि आवश्यक चीजों की तुलना में सरल चीजों को अधिक अच्छी तरह से जांचना है।

लेसन 2 सबसे कठिन इलेक्ट्रॉनिक्स बग पर भी लागू होता है, जिसे मैंने कभी भी ठीक किया था, एक तुच्छ निर्धारण के साथ, लेकिन कई स्मार्ट ईई महीनों के लिए स्टम्प्ड हो गए थे। लेकिन यह एक इलेक्ट्रॉनिक्स फोरम नहीं है, इसलिए मैं कहूंगा कि इससे अधिक नहीं।


कृपया इलेक्ट्रॉनिक्स बग को कहीं और पोस्ट करें और यहां एक लिंक दें!
tgkprog

6

नेटवर्किंग डेटा नर्क की स्थिति से नरक

मैं एक नेटवर्किंग क्लाइंट / सर्वर (विंडोज एक्सपी / सी #) को किसी अन्य डेवलपर द्वारा लिखे गए वास्तव में पुराने (एनकोर 32/77) वर्कस्टेशन पर एक समान एप्लिकेशन के साथ काम करने के लिए लिख रहा था।

एप्लिकेशन ने अनिवार्य रूप से क्या किया था, हमारे फैंसी पीसी आधारित मल्टी-मॉनिटर टचस्क्रीन यूआई के साथ सिस्टम को चलाने वाली होस्ट प्रक्रिया को नियंत्रित करने के लिए होस्ट पर कुछ डेटा को साझा / हेरफेर कर रहा था।

इसने 3 स्तरित संरचना के साथ ऐसा किया। संचार प्रक्रिया ने होस्ट से / के लिए डेटा को पढ़ा / लिखा, सभी आवश्यक प्रारूप रूपांतरण (एंडियननेस, फ्लोटिंग पॉइंट फॉर्मेट, आदि) किया और एक डेटाबेस से / के लिए मूल्यों को लिखा / पढ़ा। डेटाबेस ने comms और टचस्क्रीन UI के बीच डेटा मध्यस्थ के रूप में काम किया। टचस्क्रीन यूआई के ऐप ने पीसी पर कितने मॉनिटर संलग्न थे (यह स्वचालित रूप से यह पता चला है) के आधार पर टच स्क्रीन इंटरफेस उत्पन्न किया।

समय सीमा में, मेजबान और हमारे पीसी के बीच मूल्यों का एक पैकेट दिया गया था, जो एक बार में अधिकतम 110 ~ प्रति चक्कर ट्रिप की अधिकतम विलंबता के साथ वायर पर 128 मान भेज सकता था (यूडीपी के बीच एक प्रत्यक्ष एक्स-ओवर ईथरनेट कनेक्शन के साथ उपयोग किया गया था कम्प्यूटर)। तो, संलग्न टचस्क्रीन की चर संख्या के आधार पर अनुमत चर की संख्या सख्त नियंत्रण में थी। इसके अलावा, होस्ट (हालांकि वास्तविक समय कंप्यूटिंग के लिए उपयोग की जाने वाली साझा मेमोरी बस के साथ एक बहुत ही जटिल मल्टी-प्रोसेसर आर्किटेक्चर है) मेरे सेल फोन की प्रसंस्करण शक्ति लगभग 1/100 थी, इसलिए इसे जितना संभव हो उतना कम प्रसंस्करण करने का काम सौंपा गया था और यह सर्वर है / क्लाइंट को यह सुनिश्चित करने के लिए असेंबली में लिखा जाना था (मेजबान एक पूर्ण वास्तविक समय सिमुलेशन चला रहा था जो हमारे कार्यक्रम से प्रभावित नहीं हो सकता)।

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


समस्या को सुलझाने के लिए मैंने दोलन मूल्यों में से एक को चुना:

  • मैंने टचस्क्रीन ऐप को चेक किया, यह दोलन कर रहा था
  • मैंने डेटाबेस की जाँच की, दोलन
  • मैंने कॉम्स ऐप की जाँच की, दोलन

फिर मैंने वायरशर्क को तोड़ दिया और पैकेट कैप्चर को मैन्युअल रूप से डिकोड करना शुरू कर दिया। परिणाम:

  • ऑसिलेटिंग नहीं, लेकिन पैकेट सही नहीं दिखे, बहुत अधिक डेटा था।

मैंने बिना किसी दोष / त्रुटि का पता लगाए कॉम्स कोड के हर विवरण के माध्यम से सौ बार कदम रखा।

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

जाहिरा तौर पर, जब उसने डेटा भेजा तो वह ट्रांसमिशन से पहले डेटा की सरणी को फ्लश नहीं करता था, अनिवार्य रूप से, वह सिर्फ पुराने को अधिलेखित करने वाले नए मूल्यों के साथ उपयोग किए गए अंतिम बफर को ओवरराइट कर रहा था, लेकिन पुराने मान अभी भी हस्तांतरित नहीं किए जा रहे हैं।

इसलिए, यदि कोई मान डेटा सरणी 80 की स्थिति में था और अनुरोध किए गए मानों की सूची 80 से कम हो गई थी, लेकिन नई सूची में समान मान सम्‍मिलित था, तो दोनों मान किसी भी समय उस विशिष्ट बफ़र के लिए डेटा बफ़र में मौजूद होंगे दिया हुआ वक़्त।

डेटाबेस से पढ़ा जा रहा मूल्य उस समय के स्लाइस पर निर्भर करता है जब UI मान का अनुरोध कर रहा था।


फिक्स दर्द सरल था। डेटा बफर पर आने वाली वस्तुओं की संख्या में पढ़ें (यह वास्तव में पैकेट प्रोटोकॉल के हिस्से के रूप में निहित था) और उस आइटम की संख्या से परे बफर को न पढ़ें।


सीख सीखी:

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

  • कस्टम प्रोटोकॉल के साथ नेटवर्किंग करते समय (या सामान्य रूप से बाइनरी डेटा प्रतिनिधित्व को संभालना) सुनिश्चित करें कि जब तक आप पाइप के पार भेजे जाने वाले प्रत्येक मूल्य के प्रत्येक फ़ंक्शन को नहीं समझ लेते, तब तक आप कल्पना को पढ़ें। मेरा मतलब है, इसे तब तक पढ़ें जब तक आपकी आँखें चोट न करें। लोग व्यक्तिगत बिट्स या बाइट्स में हेरफेर करके डेटा को संभालते हैं और चीजों को करने के बहुत ही चतुर और कुशल तरीके हैं। सबसे नन्हा विस्तार गुम होने से सिस्टम टूट सकता है।

तय करने का कुल समय 2-3 दिनों के साथ था, जब मैंने इससे निराश होकर अन्य चीजों पर काम किया था।

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


5

पृष्ठ - भूमि

  • एक मिशन क्रिटिकल WCF एप्लिकेशन में एक वेबसाइट चला रहा है और बैकएंड ट्रैसेक्शनल प्रोसेसिंग प्रदान कर रहा है।
  • बड़ी मात्रा में आवेदन (प्रति सेकंड सैकड़ों कॉल)
  • कई सर्वर कई उदाहरण
  • सैकड़ों पारित यूनिट परीक्षण और अनगिनत क्यूए हमले

बग

  • जब उत्पादन के लिए ले जाया जाता है तो सर्वर समय की एक यादृच्छिक मात्रा के लिए ठीक चलता है फिर तेजी से नीचा दिखाना शुरू कर देता है और बॉक्स सीपीयू को 100% तक ले जाता है।

मैंने इसे कैसे पाया

पहले मुझे यकीन था कि यह एक सामान्य प्रदर्शन समस्या थी इसलिए मैं विस्तृत लॉगिंग बनाता हूं। डेटाबेस के लोगों से बात की गई हर कॉल पर चेक किए गए प्रदर्शन ने मुद्दों के लिए सर्वर को देखा। 1 सप्ताह

तब मुझे यकीन था कि मेरे पास एक धागा विवाद मुद्दा था। मैंने डिबग में स्थिति बनाने के प्रयास के लिए स्थिति बनाने के उपकरण बनाने के लिए किए गए अपने गतिरोध की जाँच की। बढ़ते प्रबंधन की हताशा के साथ मैंने अपने साथियों को बताया कि कैसे प्रोजेक्ट को फिर से शुरू करने से लेकर सर्वर को एक धागे तक सीमित करने तक की बातें सुझाई गईं। 1.5 सप्ताह

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

लंबी छोटी छोटी डिक्शनरी जिसमें सिर्फ x थ्रेड त्रुटियों को लिखने के लिए लॉग ऑन करने के लिए किस ट्रैक का ट्रैक रखा गया था, को सिंक्रनाइज़ नहीं किया गया था।


3

हमारे पास एक एप्लिकेशन था जो एक हार्डवेयर डिवाइस से बात कर रहा था, जो कुछ मामलों में, सही ढंग से काम करने में विफल हो जाता अगर डिवाइस भौतिक रूप से अनप्लग होता, जब तक कि उसे दो बार वापस प्लग-इन और सॉफ्ट-रीसेट नहीं किया गया होता।

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

ड्राइवर में एक बग डिवाइस के लिए एक अमान्य मान पैदा कर रहा था जब आरंभीकरण कॉल किया गया था, लेकिन डिवाइस को एक विशिष्ट स्थिति में रखने के लिए कॉल किए जाने के बाद वैल्यू को वैध डेटा के साथ अधिलेखित कर दिया गया था।

डिवाइस में स्वयं एक बैटरी थी और यह पता लगाएगा कि क्या यह मदरबोर्ड से बिजली खो गई है, और यह अस्थिर स्मृति में एक झंडा लिख ​​देगा जो यह दर्शाता है कि यह शक्ति खो गई थी, यह तब एक विशिष्ट स्थिति में प्रवेश करेगा जब अगली बार इसे चालू किया गया था, और एक विशिष्ट ध्वज को साफ करने के लिए निर्देश भेजे जाने की आवश्यकता है।

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

अंत में परिस्थितियों के सटीक सेट का पता लगाने में लगभग दो सप्ताह लग गए जो समस्या पैदा कर रहा था।


2

एक विश्वविद्यालय परियोजना के लिए हम एक वितरित पी 2 पी नोड्स प्रणाली लिख रहे थे जो फ़ाइलों को साझा करती है, यह एक दूसरे का पता लगाने के लिए मल्टीकास्टिंग का समर्थन करती है, नोड्स के कई छल्ले और एक नेमसेवर ताकि एक क्लाइंट को सौंपा जाए।

C ++ में लिखा गया है, हमने इसके लिए POCO का उपयोग किया क्योंकि यह अच्छा IO, सॉकेट और थ्रेड प्रोग्रामिंग की अनुमति देता है।


दो कीड़े थे जो हमें परेशान करते थे और हमें बहुत समय गंवाते थे, एक सच में तर्क:

बेतरतीब ढंग से, एक कंप्यूटर अपने स्थानीय आईपी के बजाय रिमोट आईपी साझा कर रहा था।

इससे क्लाइंट को उसी पीसी या नोड पर नोड से कनेक्ट करने के लिए खुद से कनेक्ट करना पड़ा।

हमने इसकी पहचान कैसे की? जब हमने नेमसर्वर में आउटपुट में सुधार किया, तो हमें बाद में पता चला जब हमने उन कंप्यूटरों को रिबूट किया, जिन्हें देने के लिए आईपी निर्धारित करने की हमारी स्क्रिप्ट गलत थी। बेतरतीब ढंग से, लो डिवाइस को eth0 डिवाइस के बजाय पहले सूचीबद्ध किया गया था ... वास्तव में बेवकूफ। इसलिए अब हम इसे eth0 से आवश्यक रूप से हार्डकोड करते हैं क्योंकि यह सभी विश्वविद्यालय कंप्यूटरों के बीच साझा किया गया है ...


और अब एक और कष्टप्रद:

बेतरतीब ढंग से, पैकेट प्रवाह बेतरतीब ढंग से विराम देगा।
जब अगला ग्राहक जुड़ता है तो यह जारी रहेगा ...

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

कोड में बहुत सारे आउटपुट के साथ हमने सिर्फ यह मान लिया कि कमांड भेजना ठीक है,
इससे हमें आश्चर्य हुआ कि वास्तविक समस्या कहां थी ... ऐसा लगता था कि जिस तरह से POCO चुनाव गलत है और हमें उपलब्ध पात्रों की जांच करनी चाहिए आने वाले सॉकेट पर।

हमने यह मान लिया कि यह एक प्रोटोटाइप में अधिक सरल परीक्षणों के रूप में काम करता है जिसमें कम पैकेट शामिल थे, इस मुद्दे का कारण नहीं था, इसलिए इसने हमें यह मान लिया कि पोल स्टेटमेंट काम कर रहा था लेकिन ... यह नहीं था। :-(


सीख सीखी:

  • नेटवर्क उपकरणों के क्रम जैसी बेवकूफ धारणाएं न बनाएं।

  • चौखटे हमेशा अपना काम (या तो कार्यान्वयन या प्रलेखन) सही नहीं करते हैं।

  • कोड में पर्याप्त आउटपुट प्रदान करें, यदि अनुमति नहीं है तो फ़ाइल में विस्तारित विवरण लॉग करना सुनिश्चित करें।

  • जब कोड यूनिट परीक्षण नहीं किया गया है (क्योंकि यह बहुत मुश्किल है) काम करने के लिए चीजों को ग्रहण नहीं करता है।


1
तारों के बिना नेटवर्किंग मुद्दों को संबोधित करना (या इसी तरह के उपकरण) इटेसल्फ के / में वीर है।
इवान प्लाइस

2

मैं अभी भी अपने सबसे कठिन बग शिकार पर हूं। यह उन लोगों में से एक है जो कभी-कभी वहाँ रहते हैं और कभी-कभी इसके बग नहीं होते हैं। यही कारण है कि मैं यहाँ हूँ, अगले दिन सुबह 6:10 बजे।

पृष्ठभूमि:

  • संदर्भ: भाषा, अनुप्रयोग, पर्यावरण, आदि।
    • PHP OS वाणिज्य
  • बग की पहचान कैसे हुई?
    • रैंडम ऑर्डर का वह काम बेतरतीब ढंग से विफल और पुनर्निर्देशित मुद्दों का हिस्सा है
  • बग की पहचान किसने या किससे की?
    • क्लाइंट, और रीडायरेक्ट समस्या स्पष्ट थी
  • बग को पुन: पेश करना कितना जटिल था?
    • मैं पुन: पेश करने में सक्षम था, लेकिन क्लाइंट सक्षम रहा है।

शिकार।

  • आपकी योजना क्या थी?
    • डिबग कोड जोड़ें, ऑर्डर भरें, डेटा को एनालाइज करें, दोहराएं
  • आपको किन कठिनाइयों का सामना करना पड़ा?
    • दोहराने योग्य समस्याओं और भयानक कोड का अभाव
  • आपत्तिजनक कोड आखिर कैसे पाया गया?
    • बहुत सारे अपमानजनक कोड पाए गए .. बस मुझे जो चाहिए वो बिलकुल नहीं था।

मारना।

  • फिक्स कितना जटिल था?
    • बहुत
  • आपने फिक्स का दायरा कैसे तय किया?
    • कोई गुंजाइश नहीं थी ... यह हर जगह था
  • फिक्स में कितना कोड शामिल था?
    • यह सब? मुझे नहीं लगता कि कोई फाइल अछूती थी

शवपरीक्षा।

  • तकनीकी रूप से मूल कारण क्या था? बफर ओवररन, आदि।
    • बुरा कोडिंग अभ्यास
  • 30,000 फीट से मूल कारण क्या था?
    • बल्कि मैं यह नहीं कहूँगा...
  • आखिरकार प्रक्रिया में कितना समय लगा?
    • हमेशा और एकदिन
  • क्या फिक्स द्वारा प्रतिकूल रूप से प्रभावित कोई विशेषता थी?
    • सुविधा? या यह एक बग है?
  • क्या तरीके, उपकरण, प्रेरणाएँ आपको विशेष रूप से उपयोगी लगीं? ... बुरी तरह से बेकार?
  • यदि आप यह सब फिर से कर सके तो? ...........
    • ctrl + एक डेल

यदि कारण "खराब कोडिंग अभ्यास" था, तो आप अपने बॉस के साथ चर्चा करना चाह सकते हैं यदि यह आपकी टीम की कोडिंग प्रथाओं को संशोधित करने का एक अच्छा समय है, और शायद सहकर्मी की समीक्षा करें?

2

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

पीडीपी -11 में एक संख्या के बगल में यह छोटा बिंदु इसे आधार के बजाय 10 बनाता है। यह एक संख्या के बगल में था जो एक लूप को सीमित करता था जिसे ग्रिड तक सीमित होना चाहिए था, जिसका आकार उसी संख्या के साथ परिभाषित किया गया था लेकिन आधार में 8।

यह अभी भी मेरे लिए खड़ा है क्योंकि इस तरह के एक छोटे से 4 पिक्सेल आकार के नुकसान की मात्रा के कारण होता है। तो निष्कर्ष क्या है? PDP-11 विधानसभा में कोड न करें।


2

मेन-फ्रेम प्रोग्राम बिना किसी कारण के काम करना बंद कर दिया

मैंने अभी इसे दूसरे प्रश्न पर पोस्ट किया है। यहां देखें पोस्ट

ऐसा इसलिए हुआ क्योंकि उन्होंने मेन-फ्रेम पर कंपाइलर का एक नया संस्करण स्थापित किया था।

अपडेट 06/11/13: (ओपी द्वारा मूल उत्तर हटा दिया गया था)

मुझे यह मुख्य-फ्रेम एप्लिकेशन विरासत में मिला। एक दिन, साफ नीले रंग से बाहर काम करना बंद कर दिया। यह बात है ... poof यह बस बंद कर दिया।

मेरा काम इसे जल्द से जल्द काम करवाना था। स्रोत कोड को दो साल के लिए संशोधित नहीं किया गया था, लेकिन अचानक इसे रोक दिया गया। मैंने कोड संकलित करने की कोशिश की और यह लाइन XX पर टूट गया। मैंने लाइन XX को देखा और मैं यह नहीं बता पाया कि लाइन XX ब्रेक क्या बना सकता है। मैंने इस एप्लिकेशन के लिए विस्तृत चश्मा मांगा और कोई नहीं था। रेखा XX अपराधी नहीं थी।

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

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

जैसा कि मैंने धीरे-धीरे इसे साफ करना शुरू कर दिया है, मैं समय-समय पर अपने काम को बचाऊंगा। एक बिंदु पर मैंने कोड को संकलित करने की कोशिश की और एक अजीब बात खुशी हुई। त्रुटि ने छलांग लगा दी थी कि वह कोड की मूल पंक्ति को पार कर गया था और अब नीचे आ गया था। इसलिए मैंने जारी रखा, और AND और शर्तों को parens के साथ speparating। जब मैंने सफाई की तो यह काम कर गया। जाओ पता लगाओ।

मैंने तब संचालन की दुकान का दौरा करने और उनसे पूछने का फैसला किया कि क्या उन्होंने हाल ही में मुख्य-फ्रेम पर कोई नया घटक स्थापित किया है। उन्होंने कहा कि हां, हमने हाल ही में कंपाइलर को अपग्रेड किया है। Hmmmm।

यह पता चला है कि पुराने संकलक ने अभिव्यक्ति की परवाह किए बिना बाएं से दाएं की ओर मूल्यांकन किया है। संकलक के नए संस्करण ने भी बाएं से दाएं की अभिव्यक्ति का मूल्यांकन किया लेकिन अस्पष्ट कोड का अर्थ है कि एंडर्स और ओआरएस के अस्पष्ट संयोजन को हल नहीं किया जा सका।

सबक मैंने इससे सीखा ... ALWAYS, ALWAYS, ALWAYS, जब वे एक-दूसरे के साथ संयोजन के रूप में उपयोग किए जाते हैं, तो स्थिति और या स्थितियों को अलग करने के लिए parens का उपयोग करते हैं।


आपके लिंक बिंदुओं को हटा दिया गया है - क्या आप उत्तर को अपडेट करना चाहेंगे?
जन्नत

1
@gnat - इसे आर्काइव.ऑर्ग पर मिला :)
माइकल रिले - AKA Gunny

1

पृष्ठभूमि:

  • संदर्भ: वेब सर्वर (C ++) जो ग्राहकों को स्वयं चेक-इन करने की अनुमति देता है
  • बग: जब पृष्ठ का अनुरोध किया जाता है, तो वह बस जवाब नहीं देगा, पूरा खेत जो है, और प्रक्रियाओं को मार दिया जाएगा (और फिर से पंजीकृत) क्योंकि उन्हें पृष्ठ की सेवा करने में बहुत लंबा (केवल कुछ सेकंड की अनुमति है)
  • कुछ उपयोगकर्ताओं ने शिकायत की थी, लेकिन यह बहुत छिटपुट था, इसलिए ज्यादातर लोगों का ध्यान नहीं गया (जब कोई पृष्ठ नहीं परोसा जाता है तो लोग "रिफ्रेश" मारते हैं)। हमने हालांकि कोर डंप को नोटिस किया;)
  • हम वास्तव में अपने स्थानीय वातावरण में पुन: पेश करने में कामयाब नहीं हुए, बग टेस्ट सिस्टम में कुछ बार दिखाई दिया, लेकिन प्रदर्शन टेस्ट के दौरान कभी नहीं दिखा ??

शिकार।

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

मारना।

  • फिक्स जटिलता: संकलित टेम्पलेट्स पर स्विच करना
  • कोड प्रभावित: कोई नहीं, निर्माण प्रक्रिया में एक साधारण बदलाव

शवपरीक्षा।

  • मूल कारण: परिचालन मुद्दा या आगे की योजना की कमी :)
  • Timescale: इसे ठीक करने में कई महीने लग गए, तय करने और परीक्षण करने के लिए कुछ दिन, क्यूए और प्रदर्शन परीक्षण और तैनाती के लिए कुछ सप्ताह - कोई जल्दी नहीं है, क्योंकि हम जानते थे कि फिक्स को तैनात करने से बग को ट्रिगर किया जाएगा ... और कुछ नहीं और ... थोड़े वास्तव में!
  • प्रतिकूल साइड-इफेक्ट्स: रनवे पर टेम्प्लेट्स को स्विच करने की असंभवता, अब वे डिलीटेड कोड में बेक किए गए हैं, हालांकि हमने फीचर का ज्यादा इस्तेमाल नहीं किया है, क्योंकि आमतौर पर टेम्प्लेट स्विच करने का मतलब है कि आपको अधिक डेटा डालने की जरूरत है। सीएसएस का उपयोग करना। ज्यादातर "छोटे" लेआउट परिवर्तनों के लिए पर्याप्त है।
  • तरीके, उपकरण: gdb+ निगरानी! बस हमें डिस्क पर संदेह करने में समय लगा, और फिर मॉनिटरिंग ग्राफ पर गतिविधि के स्पाइक्स के कारण की पहचान करें ...
  • अगली बार: सभी IO को प्रतिकूल मानें!

1

सबसे कठिन कभी नहीं मारा गया क्योंकि यह कारखाने के संचालन के साथ पूर्ण उत्पादन वातावरण के अलावा कभी भी पुन: पेश नहीं किया जा सकता है।

मैं जिस पागल को मारता था:

चित्र मुद्रण में अस्पष्ट हैं!

मैं कोड देखता हूं और मैं कुछ भी नहीं देख सकता। मैं प्रिंटर कतार से नौकरी खींचता हूं और उसकी जांच करता हूं, यह ठीक लगता है। (यह डॉस युग में था, एम्बेडेड HPGl / 2 के साथ PCL5 - वास्तव में, ड्राइंग की साजिश रचने के लिए बहुत अच्छा है और सीमित स्मृति में रेखापुंज छवि के निर्माण का कोई सिरदर्द नहीं है।) मैं इसे एक अन्य प्रिंटर को निर्देशित करता हूं जो इसे समझना चाहिए, यह ठीक है। ।

कोड वापस रोल करें, समस्या अभी भी है।

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

एक और भी अधिक भयानक था, लेकिन चूंकि यह केवल मेरे बॉक्स पर था, इसलिए मैं पहले स्थान पर नहीं था:

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

डीबग - अगर मैं कोड के माध्यम से एकल-कदम रखता हूं तो यह हमेशा सही ढंग से काम करेगा, अन्यथा यह पहले की तरह अस्थिर था। निरीक्षण ने हमेशा सही मूल्यों को दिखाया।

अपराधी: दो थे।

1) बोरलैंड के पुस्तकालय कोड में एक प्रमुख बग था: रियल मोड पॉइंटर्स को संरक्षित मोड में पॉइंटर चर में संग्रहीत किया जा रहा था। समस्या यह है कि अधिकांश वास्तविक मोड पॉइंटर्स में संरक्षित मोड में अमान्य सेगमेंट पते हैं और जब आप पॉइंटर को कॉपी करने का प्रयास करते हैं तो इसे एक रजिस्टर जोड़ी में लोड किया जाता है और फिर इसे सहेजा जाता है।

2) डिबगर सिंगल-स्टेप मोड में इस तरह के अमान्य लोड के बारे में कभी नहीं कहेगा। मुझे नहीं पता कि इसने आंतरिक रूप से क्या किया लेकिन उपयोगकर्ता को जो प्रस्तुत किया गया वह पूरी तरह से सही था। मुझे संदेह है कि यह वास्तव में निर्देश को निष्पादित नहीं कर रहा था, बल्कि इसके बजाय अनुकरण कर रहा था।


1

यह सिर्फ एक बहुत ही सरल बग है जो किसी तरह मेरे लिए बुरे सपने में बदल गया।

पृष्ठभूमि: मैं अपना खुद का ऑपरेटिंग सिस्टम बनाने पर काम कर रहा था। डिबगिंग बहुत मुश्किल है (ट्रेस स्टेटमेंट आपके पास हो सकता है, और कभी-कभी ऐसा नहीं भी होता है)

बग: दो धागे स्विचों को वर्मोड पर करने के बजाय, यह सामान्य सुरक्षा दोष होगा।

बग हंट: मैंने इस समस्या को ठीक करने में एक या दो सप्ताह का समय लगाया। हर जगह ट्रेस स्टेटमेंट डालना। उत्पन्न विधानसभा कोड की जांच (जीसीसी से)। हर एक मूल्य का मुद्रण जो मैं कर सकता था।

समस्या: बग हंट में कहीं जल्दी, मैंने hltcrt0 में एक निर्देश दिया था । Crt0 मूल रूप से एक ऑपरेटिंग सिस्टम में उपयोग के लिए उपयोगकर्ता प्रोग्राम को बूटस्ट्रैप करता है। यह hltनिर्देश उपयोगकर्ता मोड से निष्पादित होने पर GPF का कारण बनता है। मैंने इसे वहां रखा और मूल रूप से इसके बारे में भूल गया। (मूल रूप से समस्या एक बफर अतिप्रवाह या मेमोरी आवंटन त्रुटि की कुछ थी)

फिक्स: hltनिर्देश को हटा दें :) इसे हटाने के बाद, सब कुछ सुचारू रूप से काम करता है।

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.