debugging - समस्या का हल




एक डीबगर क्या है और यह समस्याओं का निदान करने में मेरी सहायता कैसे कर सकता है? (2)

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

इस प्रश्न में दो विशिष्ट प्रश्नों के दो वर्ग शामिल हैं:

  • जब मैं अपना प्रोग्राम चलाता हूं, तो यह उस आउटपुट का उत्पादन नहीं करता है जिसे मैं इनपुट के लिए उम्मीद करता हूं
  • जब मैं अपना प्रोग्राम चलाता हूं, तो यह दुर्घटनाग्रस्त हो जाता है और मुझे एक स्टैक ट्रेस देता है। मैंने स्टैक ट्रेस की जांच की है , लेकिन मुझे अभी भी समस्या का कारण पता नहीं है क्योंकि स्टैक ट्रेस मुझे पर्याप्त जानकारी प्रदान नहीं करता है।

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

ऐसा करने से आप यह पता लगा सकते हैं कि किसी चर के पास गलत मान है, और जहां आपके प्रोग्राम में इसका मान गलत मान में बदल गया है।

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

डीबगर का उपयोग करने के विनिर्देश डीबगर पर निर्भर करते हैं, और कम डिग्री के लिए, प्रोग्रामिंग भाषा जिसका आप उपयोग कर रहे हैं।

  • आप पहले से ही अपने प्रोग्राम को चलाने वाली प्रक्रिया में डीबगर संलग्न कर सकते हैं । यदि आपका प्रोग्राम फंस गया है तो आप कर सकते हैं।

  • अभ्यास में शुरुआत से ही अपने प्रोग्राम को डीबगर के नियंत्रण में चलाने में आसान होता है।

  • आप इंगित करते हैं कि आपके प्रोग्राम को स्रोत-कोड फ़ाइल और लाइन की लाइन संख्या को इंगित करके निष्पादन करना बंद करना चाहिए, जिस पर निष्पादन रोकना चाहिए, या उस विधि / फ़ंक्शन का नाम इंगित करके जिस पर प्रोग्राम रोकना चाहिए (यदि आप रुकना चाहते हैं जैसे ही निष्पादन विधि में प्रवेश करता है)। तकनीकी का मतलब है कि आपके प्रोग्राम को रोकने के लिए डीबगर का उपयोग ब्रेकपॉइंट कहा जाता है और इस प्रक्रिया को ब्रेकपॉइंट सेट करने के लिए कहा जाता है।

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

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


मैं यह जोड़ना चाहता हूं कि एक डीबगर हमेशा सही समाधान नहीं होता है, और हमेशा डीबगिंग के लिए जाने-जाने के समाधान नहीं होना चाहिए। यहां कुछ ऐसे मामले दिए गए हैं जहां एक डीबगर आपके लिए काम नहीं कर सकता है:

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

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

तो फिर विकल्प क्या हैं?

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

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

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

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

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








language-agnostic