अन्य भाषाओं में पढ़ें: अंग्रेजी पुर्तगाली 中文

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

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

समस्या

यदि आप उदाहरण का अनुसरण करना चाहते हैं, तो इस रिपॉजिटरी को क्लोन करके प्रारंभ करें: https://github.com/flounder4130/debugger-example

मान लीजिए कि आपके पास एक जटिल एप्लिकेशन है जो कुछ कार्रवाई करने पर क्रैश हो जाता है। आप जानते हैं कि त्रुटि को कैसे पुन: उत्पन्न किया जाए, लेकिन कठिनाई यह है कि आप नहीं जानते कि कोड का कौन सा भाग इस कार्यक्षमता के लिए जिम्मेदार है।

हमारे उदाहरण एप्लिकेशन में, क्रैश तब होता है जब आप बटन एन पर क्लिक करते हैं। हालाँकि, उस कोड को ढूंढना इतना आसान नहीं है जो इस क्रिया के लिए ज़िम्मेदार है:

आइए देखें कि हम इसे खोजने के लिए डिबगर का उपयोग कैसे कर सकते हैं।

विधि विरामबिंदु

लाइन ब्रेकप्वाइंट की तुलना में विधि ब्रेकप्वाइंट का लाभ यह है कि उनका उपयोग कक्षाओं के संपूर्ण पदानुक्रम में किया जा सकता है। यह हमारे मामले में कैसे उपयोगी है?

यदि आप उदाहरण प्रोजेक्ट को देखते हैं, तो आप देखेंगे कि सभी एक्शन क्लास एक्शन इंटरफ़ेस से एक ही विधि से प्राप्त होते हैं: प्रदर्शन()।

इस इंटरफ़ेस विधि पर एक विधि ब्रेकप्वाइंट सेट करने से हर बार व्युत्पन्न विधियों में से एक को कॉल करने पर एप्लिकेशन निलंबित हो जाएगा। विधि ब्रेकप्वाइंट सेट करने के लिए, विधि घोषित करने वाली पंक्ति पर क्लिक करें।

डिबगिंग सत्र प्रारंभ करें और बटन N पर क्लिक करें। एप्लिकेशन ActionImpl14 पर निलंबित है। अब हम जानते हैं कि इस बटन से संबंधित कोड कहां स्थित है।

हालाँकि इस लेख में हमारा ध्यान बग ढूंढने पर केंद्रित है, यह तकनीक आपका काफी समय भी बचा सकती है जब आप यह समझना चाहते हैं कि बड़े कोड बेस में कोई चीज़ कैसे काम करती है।

आवेदन रोकें

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

ठीक है, हम इसे बिना ब्रेकप्वाइंट के भी कर सकते हैं। बटन N पर क्लिक करें, और जब एप्लिकेशन हैंग हो जाए, तो IntelliJ IDEA पर जाएं। मुख्य मेनू से, Run | चुनें डिबगिंग क्रियाएँ | प्रोग्राम रोकें।

एप्लिकेशन निलंबित हो जाएगा, जिससे हम थ्रेड्स और वेरिएबल्स टैब में थ्रेड्स की वर्तमान स्थिति की जांच कर सकेंगे। इससे हमें पता चलता है कि एप्लिकेशन उस समय क्या कर रहा है। चूंकि यह हैंग हो रहा है, हम ब्लॉक का कारण बनने वाली विधि की पहचान कर सकते हैं और इसे कॉल साइट पर वापस ढूंढ सकते हैं।

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

टिप: पॉज़ प्रोग्राम के साथ अधिक युक्तियों और युक्तियों के लिए ब्रेकप्वाइंट के बिना डिबगिंग और Debugger.godMode()

थ्रेड डंप

अंत में, हम थ्रेड डंप का उपयोग कर सकते हैं, जो पूरी तरह से डिबगर सुविधा नहीं है। चाहे आप डिबगर का उपयोग कर रहे हों या नहीं, यह उपलब्ध है।

बटन एन पर क्लिक करें। जब एप्लिकेशन क्रैश हो रहा हो, तो IntelliJ IDEA पर जाएं। मुख्य मेनू से, Run | चुनें डिबगिंग क्रियाएँ | थ्रेड डंप प्राप्त करें।

बाईं ओर उपलब्ध थ्रेड्स का अन्वेषण करें, और AWT-EventQueue में आप देखेंगे कि समस्या का कारण क्या है।

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

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

समस्या को समझें

डिबगिंग तकनीक के बावजूद, हम ActionImpl14 पर पहुंचते हैं। इस वर्ग में, किसी ने काम को एक अलग थ्रेड में करने का इरादा किया, लेकिन थ्रेड.स्टार्ट() को थ्रेड.रन() के साथ भ्रमित कर दिया, जो कॉलिंग कोड के समान थ्रेड में कोड चलाता है।

InteliJ IDEA का स्थैतिक विश्लेषक हमें डिज़ाइन समय पर इसके बारे में चेतावनी भी देता है:

एक विधि जो भारी वजन उठाती है (या इस मामले में बहुत अधिक सोती है) को यूआई थ्रेड पर कॉल किया जाता है और विधि समाप्त होने तक इसे ब्लॉक कर दिया जाता है। इसीलिए हम बटन एन पर क्लिक करने के बाद कुछ देर तक यूआई में कुछ नहीं कर सकते।

हॉट स्वैप

अब जब हमें त्रुटि का कारण पता चल गया है, तो आइए समस्या को ठीक करें।

हम प्रोग्राम को रोक सकते हैं, कोड को दोबारा संकलित कर सकते हैं, और फिर इसे फिर से चला सकते हैं। हालाँकि, सिर्फ इसलिए कि एक छोटा सा बदलाव किया गया था, पूरे एप्लिकेशन को फिर से तैनात करना हमेशा बुद्धिमानी नहीं है।

आइए इसे स्मार्ट तरीके से करें। सबसे पहले, सुझाए गए त्वरित सुधार का उपयोग करके कोड को ठीक करें:

कोड तैयार होने के बाद, Run | पर क्लिक करें डिबगिंग क्रियाएँ | परिवर्तित कक्षाओं को पुनः लोड करें। एक गुब्बारा प्रकट होता है, जो पुष्टि करता है कि नया कोड वीएम में आ गया है।

आइए एप्लिकेशन पर वापस जाएं और जांच करें। बटन एन पर क्लिक करने से अब एप्लिकेशन क्रैश नहीं होता है।

टिप: ध्यान रखें कि हॉटस्वैप की अपनी सीमाएं हैं। यदि आप विस्तारित हॉटस्वैप क्षमताओं में रुचि रखते हैं, तो DCEVM या JRebel जैसे उन्नत टूल पर नज़र डालना एक अच्छा विचार हो सकता है

सारांश

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

मुझे आशा है कि आपको वर्णित तकनीकें उपयोगी लगेंगी। मुझे जानने दो जो आप सोचते हो!

यदि आप डिबगिंग और प्रोफाइलिंग से संबंधित अधिक लेखों में रुचि रखते हैं, तो मेरे कुछ अन्य लेख देखें:

• Debugger.godMode() - डिबगर के साथ एक JVM एप्लिकेशन को हैक करें
• धीमे डिबगर का समस्या निवारण करें
• createDirectories() में क्या गलत है? - सीपीयू प्रोफाइलिंग के लिए गाइड
• ब्रेकप्वाइंट के बिना डिबग

अधिक जानकारी के लिए बने रहें!