एक प्रक्रिया के रूप में डिबगिंग

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

इस प्रकार, डिबगिंग प्रक्रिया का अनुकूलन और व्यवस्थितकरण सहेजे गए मानव-घंटे के रूप में महत्वपूर्ण लाभ ला सकता है, समस्या को हल करने की गति बढ़ाता है और अंततः, अपने उपयोगकर्ताओं की वफादारी बढ़ाता है।



DotNext 2018 Piter कॉन्फ्रेंस में सर्गेई शेचग्रीकोविच (डॉटमेलर) ने डिबगिंग को एक प्रक्रिया के रूप में देखने का सुझाव दिया जिसे वर्णित और अनुकूलित किया जा सकता है। यदि आपके पास अभी भी बग ढूंढने की स्पष्ट योजना नहीं है - सर्गेई की रिपोर्ट के कट वीडियो और टेक्स्ट ट्रांसक्रिप्ट के तहत।

(और पोस्ट के अंत में, हमने सभी सहयोगियों से जॉन स्कीट की अपील को जोड़ा, अवश्य देखें)



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

हम डिबगिंग के दौरान संचार के लिए एक सामान्य भाषा विकसित करेंगे, और हम मुख्य समस्याओं को खोजने के लिए एक सीधा रास्ता भी देखेंगे। अपने उदाहरणों पर मैं दिखाऊंगा कि इन नियमों के उल्लंघन के कारण क्या हुआ।

डीबग उपयोगिताएँ

बेशक, कोई भी डीबगिंग उपयोगिताओं को डीबग किए बिना संभव नहीं है। मेरा पसंदीदा हैं:

• विंडबग , जो खुद डिबगर के अलावा, मेमोरी डंप का अध्ययन करने के लिए समृद्ध कार्यक्षमता है। एक मेमोरी डंप एक प्रक्रिया की स्थिति का एक टुकड़ा है। इसमें आप वस्तुओं के क्षेत्र, कॉल-स्टैक्स का मूल्य पा सकते हैं, लेकिन, दुर्भाग्य से, मेमोरी डंप स्थिर है।
  
• PerfView , ETW तकनीक के शीर्ष पर लिखा गया एक प्रोफाइलर है।
  
• Sysinternals Mark Russinovich द्वारा लिखी गई एक उपयोगिता है, जो आपको ऑपरेटिंग सिस्टम के उपकरण में थोड़ी और खुदाई करने की अनुमति देती है।
  

गिरने वाली सेवा

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

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

सेवा .Net 3.0 के तहत लिखी गई थी और यह बहुत समय पहले थी। इस सेवा की एक छोटी विशेषता थी - यह दुर्घटनाग्रस्त हो गई। प्रायः हर दो से तीन घंटे में एक बार फेल होता है। हमने यह निश्चित रूप से तय किया - गिरावट के बाद सेवा के गुणों में पुनः आरंभ गुण सेट करें।



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

अगर कुछ काम नहीं करता है तो .NET डेवलपर्स कहां जाते हैं? वे EventViewer पर जाएं। लेकिन वहाँ मुझे रिकॉर्ड के अलावा कुछ भी नहीं मिला कि सेवा गिर गई। मूल त्रुटि के बारे में कोई संदेश नहीं थे, न ही कॉल-स्टैक।



आगे क्या करना है इसके लिए एक सिद्ध उपकरण है - हम पूरे main को try-catch में लपेटते हैं।

 try { ProcessRequest(); } catch (Exception ex) { LogError(ex); } 

विचार सरल है: try-catch काम करेगा, यह हमें बग देगा, हम इसे पढ़ेंगे और सेवा को ठीक करेंगे। हम संकलन करते हैं, उत्पादन के लिए तैनात करते हैं, सेवा क्रैश हो जाती है, कोई त्रुटि नहीं है। एक और catch जोड़ें।

 try { ProcessRequest(); } catch (Exception ex) { LogError(ex); } catch { LogError(); } 

हम प्रक्रिया को दोहराते हैं: सेवा क्रैश हो जाती है, लॉग में कोई त्रुटि नहीं है। आखिरी चीज जो मदद कर सकती है, वह finally , जिसे हमेशा कहा जाता है।

 try { ProcessRequest(); } catch (Exception ex) { LogError(ex); } catch { LogError(); } finally { LogEndOfExecution(); } 

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

दो सप्ताह बीत चुके हैं।



मैंने PerformanceMonitor में देखा, जहां मैंने एक सेवा देखी जो दुर्घटनाग्रस्त हो जाती है, फिर बढ़ जाती है, फिर गिर जाती है। इस स्थिति को निराशा कहा जाता है और इस तरह दिखता है:



इस तरह के लेबल में, आप यह पता लगाने की कोशिश कर रहे हैं कि समस्या वास्तव में कहां है? कई घंटों के ध्यान के बाद, समस्या अचानक प्रकट होती है:



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

हम एक मेमोरी डंप लेते हैं, इसे WinDbg में खोलें। हम कमांड निष्पादित करना शुरू करते हैं। आइए उन वस्तुओं की अंतिम कतार को देखने का प्रयास करें जिन्हें आवेदन द्वारा मुक्त किया जाना चाहिए।

 0:000> !FinalizeQueue 

सूची के अंत में, मुझे एक वेब ब्राउज़र मिला।


समाधान सरल है - WebBrowser लें और इसके लिए कॉल dispose करें:

 private void Process() { using (var webBrowser = new WebBrowser()) { // Processing ... } } 

इस कहानी से निष्कर्ष निम्नानुसार निकाला जा सकता है: दो सप्ताह बहुत लंबा है और एक बिन बुलाए खोजने के लिए बहुत लंबा है; हमें समस्या का समाधान मिला - भाग्य, क्योंकि कोई विशिष्ट दृष्टिकोण नहीं था, कोई व्यवस्थित प्रकृति नहीं थी।

उसके बाद, मेरा एक सवाल था: प्रभावी ढंग से कैसे शुरुआत करें और क्या करें?

ऐसा करने के लिए, आपको केवल तीन चीजों को जानना होगा:

1. डिबगिंग नियम
   
2. त्रुटियों को खोजने के लिए एल्गोरिदम।
   
3. सक्रिय डिबगिंग तकनीक।
   

डिबगिंग नियम

1. गलती को दोहराएं।
   
2. यदि आपने त्रुटि ठीक नहीं की है, तो यह तय नहीं है।
   
3. सिस्टम को समझें।
   
4. प्लग की जाँच करें।
   
5. फूट डालो और जीतो।
   
6. तरोताजा होना।
   
7. यह आपका बग है।
   
8. पाँच क्यों।
   

ये बहुत स्पष्ट नियम हैं जो खुद का वर्णन करते हैं।

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

यदि आपने त्रुटि ठीक नहीं की है, तो यह तय नहीं है। कभी-कभी ऐसा होता है: एक बग ट्रैकर में एक बग होता है जो आधे साल पहले दिखाई देता था, किसी ने इसे लंबे समय तक नहीं देखा है, और बस इसे बंद करने की इच्छा है। लेकिन इस समय हम यह जानने का मौका चूक जाते हैं, यह समझने का मौका कि हमारा सिस्टम कैसे काम करता है और वास्तव में इसका क्या होता है। इसलिए, कोई भी बग कुछ सीखने, अपने सिस्टम के बारे में अधिक जानने का एक नया अवसर है।

सिस्टम को समझें। ब्रायन केर्निघन ने एक बार कहा था कि अगर हम इस प्रणाली को लिखने के लिए इतने स्मार्ट थे, तो हमें इसे शुरू करने के लिए दोगुना स्मार्ट होने की आवश्यकता है।

नियम का एक छोटा सा उदाहरण। हमारी निगरानी रेखाचित्र बनाती है:


यह हमारी सेवा द्वारा संसाधित अनुरोधों की संख्या का एक ग्राफ है। एक बार इसे देखने के बाद, हम इस विचार के साथ आए कि सेवा की गति बढ़ाना संभव होगा। इस स्थिति में, शेड्यूल बढ़ता है, सर्वर की संख्या को कम करना संभव हो सकता है।

वेब-प्रदर्शन का अनुकूलन बस किया जाता है: हम PerfView लेते हैं, इसे उत्पादन मशीन पर चलाते हैं, यह 3-4 मिनट के भीतर ट्रेस को हटा देता है, हम इस ट्रेस को स्थानीय मशीन पर ले जाते हैं और इसका अध्ययन करना शुरू करते हैं।

परफ़ेक्ट व्यू दिखाता है कि आँकड़ों में से एक कचरा संग्राहक है।



इन आँकड़ों को देखते हुए, हमने देखा कि यह सेवा अपना 85% समय कचरा इकट्ठा करने में व्यतीत करती है। आप परफेक्ट व्यू में देख सकते हैं कि यह समय कहाँ बिताया गया है।



हमारे मामले में, यह तार पैदा कर रहा है। सुधार स्वयं ही सुझाव देता है: हम सभी स्ट्रिंग को स्ट्रिंगरबिल्डर्स से बदल देते हैं। स्थानीय रूप से, हमें 20-30% की उत्पादकता वृद्धि मिलती है। उत्पादन पर निर्भर, पुराने शेड्यूल की तुलना में परिणाम देखें:



"सिस्टम को समझें" नियम केवल यह समझने के बारे में नहीं है कि आपके सिस्टम में बातचीत कैसे चल रही है, संदेश कैसे जाते हैं, बल्कि इस प्रणाली को मॉडल करने की कोशिश कर रहे हैं।

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

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

"प्लग की जाँच करें" नियम तथ्यों और डेटा के बारे में है। डिबगिंग WinDbg या PerfView को प्रोडक्शन मशीनों पर चलाने से शुरू नहीं होता है, यह तथ्यों और डेटा की जांच करके शुरू होता है। यदि सेवा जवाब नहीं दे रही है, तो यह बस नहीं चल सकती है।

फूट डालो और जीतो। यह पहला और शायद एकमात्र नियम है जिसमें एक प्रक्रिया के रूप में डीबगिंग शामिल है। यह परिकल्पना, उनके प्रचार और परीक्षण के बारे में है।

हमारी एक सेवा को रोकना नहीं चाहता था।



हम एक परिकल्पना करते हैं: शायद इस परियोजना में एक चक्र है जो कुछ अंतहीन प्रक्रिया करता है।

आप विभिन्न तरीकों से परिकल्पना का परीक्षण कर सकते हैं, एक विकल्प मेमोरी डंप लेना है। हम ~*e!ClrStack का उपयोग करके डंप और सभी थ्रेड्स से कॉल-स्टैक ~*e!ClrStack । हम तीन धाराओं को देखना और देखना शुरू करते हैं।







पहला धागा मेन में है, दूसरा OnStop() हैंडलर में है, और तीसरा धागा कुछ आंतरिक कार्यों की प्रतीक्षा कर रहा है। इस प्रकार, हमारी परिकल्पना उचित नहीं है। कोई लूपिंग नहीं है, सभी धागे किसी चीज का इंतजार कर रहे हैं। सबसे अधिक संभावना गतिरोध।

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

हम दूसरी परिकल्पना करते हैं: शायद हमारे पास दूसरे के लिए एक कार्य का गतिरोध है। इसे जांचने के लिए, आप प्रत्येक कार्य को WinDbg के माध्यम से अलग से देख सकते हैं।



यह पता चला है कि एक कार्य गिर गया, और दूसरा नहीं हुआ। परियोजना में, हमने निम्नलिखित कोड देखा:

 await openAsync(); _initLock.SetResult(true); 

इसका मतलब है कि इनिशियलाइज़ेशन टास्क कनेक्शन खोलता है और इसके बाद टास्क TaskCompletionSource को सच करता है। लेकिन क्या होगा अगर एक अपवाद यहाँ पड़ता है? तब हमारे पास सेट करने के लिए सेट करने का समय नहीं है। सत्य पर, इसलिए इस बग को ठीक करना इस तरह था:

 try { await openAsync(); _initLock.SetResult(true); } catch(Exception ex) { _initLock.SetException(ex); } 

इस उदाहरण में, हम दो परिकल्पनाओं को सामने रखते हैं: अनंत लूप और गतिरोध। नियम "विभाजित और जीत" त्रुटि को स्थानीय बनाने में मदद करता है। क्रमिक अनुमान ऐसी समस्याओं को हल करते हैं।

इस नियम में सबसे महत्वपूर्ण बात परिकल्पना है, क्योंकि समय के साथ वे पैटर्न में बदल जाते हैं। और परिकल्पना के आधार पर, हम विभिन्न क्रियाओं का उपयोग करते हैं।

तरोताजा होना। यह नियम है कि आपको केवल टेबल से उठने और चलने, पानी पीने, जूस या कॉफी पीने, कुछ भी करने की ज़रूरत है, लेकिन सबसे महत्वपूर्ण बात यह है कि आपकी समस्या को दूर करना है।

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

यह आपका बग है। मैं एक उदाहरण द्वारा इस नियम के बारे में बताऊंगा।

एक AccessViolationException में एक समस्या थी। कॉल-स्टैक में देखते हुए, मैंने देखा कि यह तब हुआ जब हमने sql क्लाइंट के अंदर LinqToSql क्वेरी उत्पन्न की।



इस बग से यह स्पष्ट था कि कहीं न कहीं स्मृति की अखंडता का उल्लंघन होता है। सौभाग्य से, उस समय हमने पहले से ही परिवर्तन प्रबंधन प्रणाली का उपयोग किया था। नतीजतन, कुछ घंटों के बाद यह स्पष्ट हो गया कि क्या हुआ: हमने अपने उत्पादन मशीनों पर .Net 4.5.2 स्थापित किया।



तदनुसार, हम बग को Microsoft को भेजते हैं, वे इसकी जांच करते हैं, हम उनके साथ संवाद करते हैं, वे .net 4.6.1 में बग को ठीक करते हैं।



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

पाँच क्यों। हम अपनी कंपनी में इलास्टिक का उपयोग करते हैं। लॉग एकत्रीकरण के लिए लोचदार अच्छा है।

आप सुबह काम पर आते हैं, और इलास्टिक झूठ बोलते हैं।



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

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

इन नियमों का अनुप्रयोग आपको वास्तविक समस्याओं को प्रकट करने की अनुमति देता है, इन समस्याओं को हल करने के लिए आपका ध्यान केंद्रित करता है और संवाद करने में मदद करता है। लेकिन यह बेहतर होगा यदि ये नियम एक प्रणाली का गठन करें। और ऐसी एक प्रणाली है, इसे डीबगिंग एल्गोरिदम कहा जाता है।

डीबगिंग एल्गोरिदम

पहली बार मैंने जॉन रोबिन्स की पुस्तक डीबगिंग अनुप्रयोगों में डीबगिंग एल्गोरिथ्म के बारे में पढ़ा। यह डिबगिंग प्रक्रिया का वर्णन इस प्रकार है:



यह एल्गोरिथ्म इसके आंतरिक पाश के लिए उपयोगी है - एक परिकल्पना के साथ काम करना।

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

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

इस एल्गोरिथ्म के लिए मेरे पास एक अच्छा उदाहरण है। हमारी वेब सेवाओं में से एक पर एक अपवाद गिर गया।



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

सबसे पहले, त्रुटि को दोहराएं। प्रत्येक हजार अनुरोधों के लिए, लगभग एक StructureMapException , इसलिए हम समस्या को पुन: उत्पन्न कर सकते हैं।

दूसरे, हम समस्या का वर्णन करने का प्रयास कर रहे हैं: यदि उपयोगकर्ता उस समय हमारी सेवा के लिए http अनुरोध करता है, जब स्ट्रक्च्योरपाइप एक नई निर्भरता बनाने की कोशिश कर रहा है, तो एक अपवाद होता है।

तीसरा, हम इस बात की परिकल्पना करते हैं कि स्ट्रक्चर्डपॉपर एक रैपर है और अंदर कुछ ऐसा है जो आंतरिक अपवाद को फेंकता है। हम procdump.exe का उपयोग करके परिकल्पना का परीक्षण करते हैं।

 procdump.exe -ma -e -f StructureMap w3wp.exe 

यह पता चला है कि अंदर एक NullReferenceException ।



इस अपवाद के कॉल-स्टैक का अध्ययन करते हुए, हम समझते हैं कि यह स्ट्रक्चुरेस्पोर्ट में ऑब्जेक्ट-बिल्डर के अंदर ही होता है।



लेकिन NullReferenceException समस्या स्वयं नहीं है, बल्कि परिणाम है। आपको यह समझने की आवश्यकता है कि यह कहां होता है और इसे कौन उत्पन्न करता है।

हमने निम्नलिखित परिकल्पना को आगे रखा: किसी कारण से, हमारा कोड एक अशक्त निर्भरता देता है। यह देखते हुए कि .Net में सभी ऑब्जेक्ट्स एक-एक करके स्थित होते हैं, अगर हम NullReferenceException पहले झूठ बोलने वाले ढेर पर वस्तुओं को देखते हैं, तो वे संभवतः उस कोड को इंगित करेंगे जो अपवाद को फेंक दिया था।

WinDbg में एक कमांड होती है - लिस्ट नियर ऑब्जेक्ट्स !lno । यह दर्शाता है कि जिस वस्तु में हम रुचि रखते हैं, वह लैम्ब्डा फ़ंक्शन है, जिसका उपयोग निम्नलिखित कोड में किया जाता है।

 public CompoundInterceptor FindInterceptor(Type type) { CompoundInterceptop interceptor; if (!_analyzedInterceptors.TryGetValue(type, out interceptor)) { lock (_locker) { if (!_analyzedInterceptors.TryGetValue(type, out interceptor)) { var interceptorArray = _interceptors.FindAll(i => i.MatchesType(type)); interceptor = new CompoundInterceptor(interceptorArray); _analyzedInterceptors.Add(type, interceptor); } } } return interceptor; } 

इस कोड में, हम पहले _analyzedInterceptors कि क्या Dictionary में मूल्य _analyzedInterceptors में _analyzedInterceptors है, अगर हमें नहीं मिला, तो lock अंदर एक नया मान जोड़ें।

सिद्धांत रूप में, यह कोड कभी भी शून्य नहीं लौट सकता है। लेकिन यहां समस्या _analyzedInterceptors , जो एक बहु-थ्रेडेड वातावरण में एक नियमित Dictionary का उपयोग करता है, न कि ConcurrentDictionary ।

समस्या की जड़ पाई गई, हमने स्ट्रक्चुरपेज़ के नवीनतम संस्करण में अपडेट किया, तैनात किया, यह सुनिश्चित किया कि सब कुछ तय हो गया था। हमारे एल्गोरिथ्म का अंतिम चरण "सीखना और बताना" है। हमारे मामले में, यह सभी Dictionary के कोड में एक खोज थी जिसका उपयोग लॉक और जाँच में किया जाता है कि इन सभी का सही उपयोग किया जाता है।

तो, डिबगिंग एल्गोरिथ्म एक सहज ज्ञान युक्त एल्गोरिथ्म है जो समय बचाता है। वह परिकल्पना पर ध्यान केंद्रित करता है - और यह डिबगिंग में सबसे महत्वपूर्ण बात है।

प्रोएक्टिव डिबगिंग

इसके मूल में, सक्रिय डिबगिंग प्रश्न का उत्तर देता है "जब एक बग दिखाई देता है तो क्या होता है।"



बग जीवनचक्र आरेख में सक्रिय डिबगिंग तकनीकों का महत्व देखा जा सकता है।



समस्या यह है कि बग जितना लंबा रहता है, उतने अधिक संसाधन (समय) हम उस पर खर्च करते हैं।

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

एमडीपी में दो चीजें शामिल हैं: फिटनेस फ़ंक्शन और यूएसई विधि।

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

एमडीपी के मामले में, फिटनेस फ़ंक्शन एक डिबगैबिलिटी टेस्ट है। इस तरह के परीक्षण लिखने के लिए आप कुछ भी उपयोग कर सकते हैं: NUnit, MSTest इत्यादि। लेकिन, चूंकि डिबगिंग अक्सर बाहरी उपकरणों के साथ काम कर रहा है, मैं उदाहरण के तौर पर Pester (पावरशेल यूनिट टेस्टिंग फ्रेमवर्क) का उपयोग करके प्रदर्शित करूंगा। इसका प्लस यहाँ है कि यह कमांड लाइन के साथ अच्छी तरह से काम करता है।

उदाहरण के लिए, कंपनी के अंदर हम सहमत हैं कि हम लॉगिंग के लिए विशिष्ट पुस्तकालयों का उपयोग करेंगे; लॉगिंग करते समय हम विशिष्ट पैटर्न का उपयोग करेंगे; pdb अक्षर हमेशा प्रतीक सर्वर को दिए जाने चाहिए। यह वे सम्मेलन होंगे जिन्हें हम अपने परीक्षणों में परखेंगे।

 Describe 'Debuggability' { It 'Contains line numbers in PDBs' { Get-ChildItem -Path . -Recurse -Include @("*.exe", "*. dll ") ` | ForEach-Object { &symchk.exe /v "$_" /s "\\network\" *>&1 } ` | Where-Object { $_ -like "*Line nubmers: TRUE*" } ` | Should -Not –BeNullOrEmpty } } 

यह परीक्षण इस बात की पुष्टि करता है कि सभी pdb अक्षर प्रतीक सर्वर को दिए गए थे और सही ढंग से दिए गए थे, यानी जिनके अंदर लाइन नंबर थे। ऐसा करने के लिए, उत्पादन का संकलित संस्करण लें, सभी exe और dll फ़ाइलों को ढूंढें, इन सभी बायनेरिज़ को syschk.exe उपयोगिता के माध्यम से पास करें, जो विंडोज़ पैकेज के लिए डीबगिंग टूल में शामिल है। Syschk.exe सुविधा बाइनरी को प्रतीक सर्वर के साथ जांचती है और, अगर यह वहां एक pdb फ़ाइल पाता है, तो इसके बारे में एक रिपोर्ट प्रिंट करता है। रिपोर्ट में, हम "लाइन नंबर: TRUE" लाइन की तलाश करते हैं। और अंतिम में हम जांचते हैं कि परिणाम "शून्य या रिक्त" नहीं है।

इन परीक्षणों को एक सतत तैनाती पाइपलाइन में एकीकृत किया जाना चाहिए। एकीकरण परीक्षण और इकाई परीक्षण बीत जाने के बाद, फिटनेस फ़ंक्शन लॉन्च किए जाते हैं।

मैं कोड में आवश्यक पुस्तकालयों की जांच के साथ एक और उदाहरण दिखाऊंगा।

 Describe 'Debuggability' { It 'Contains package for logging' { Get-ChildItem -Path . -Recurse -Name "packages.config" ` | ForEach-Object { Get-Content "$_" } ` | Where-Object { $_ -like "*nlog*" } ` | Should -Not –BeNullOrEmpty } } 

परीक्षण में, हम सभी पैकेजों को लेते हैं। फाइल को बंद कर देते हैं और उन में नोडल लाइब्रेरी खोजने की कोशिश करते हैं। इसी तरह, हम यह सत्यापित कर सकते हैं कि सहसंबंध आईडी फ़ील्ड को नोड फ़ील्ड के अंदर उपयोग किया जाता है।

उपयोग के तरीके। एमडीपी के अंतिम चीज़ में वे मैट्रिक्स होते हैं जिन्हें आपको इकट्ठा करने की आवश्यकता होती है।

मैं USE पद्धति के उदाहरण से प्रदर्शित करूंगा, जिसे ब्रेंडन ग्रेग ने लोकप्रिय बनाया था। : - , : utilization (), saturation (), errors (), .

, Circonus ( monitoring soft), .



, , , — , — , — , . , USE- .

- -, , , :

• — .
  
• — .
  
• — .
  

, . , .



, , — . , , 4-5% CPU.



— , . etrace.

 etrace --kernel Process ^ --where ProcessName=Ex5-Service ^ --clr Exception 

realtime ETW-events .



, OutOfMemoryException . , , ? — , , .

 while (ShouldContinue()) { try { Do(); } catch (OutOfMemoryException) { Thread.Sleep(100); GC.CollectionCount(2); GC.WaitForPendingFinalizers(); } } 

— - . , .

 public class Cache { private static ConcurrentDictionary<int, String> _items = new ... private static DateTime _nextClearTime = DateTime.UtcNow; public String GetFromCache(int key) { if (_nextClearTime < DateTime.UtcNow) { _nextClearTime = DateTime.UtcNow.AddHours(1); _items.Clear(); } return _items[key]; } } 

, . , . USE .



— , .

, , .

• — . , , — . — , -. , .
  
• . ; Exception , , - .
  
• Minimum Debuggable Product — , .
  

, ?

1. .
   
2. .
   
3. .
   

---

— Jon Skeet. DotNext , ( ).