👶🏼 ✏️ 🧓🏾 डिबगर सीखना, भाग एक 🕺🏾 👨‍⚕️ 😓

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

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

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

लेख का आयतन अप्रत्याशित रूप से बड़ा निकला, इसलिए मैंने इसे तीन भागों में तोड़ दिया:

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

दरअसल, चलो शुरू हो जाओ।

1.1। ब्रेकप्वाइंट का उपयोग करना और स्थानीय चर को संशोधित करना

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

BP को स्थापित और हटाने का सबसे आसान तरीका हॉटकी "F5" (या मेनू में इसका एनालॉग "डीबग-> टॉगल ब्रेकपॉइंट") है। अन्य तरीके हैं, लेकिन बाद में उनके बारे में अधिक।

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

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

ब्रेकपॉइंट सेट करना और कोड की प्रत्येक पंक्ति को क्रमिक रूप से निष्पादित करना बहुत आसान है, घंटों खर्च करने की तुलना में समान कोड का अध्ययन करके यह पता लगाने की कोशिश करना कि यह हमारे उद्देश्य से अलग तरीके से काम करना शुरू कर देता है।

आइए निम्नलिखित उदाहरण देखें।

एक कार्य है: कोड लिखें जो शुरू में अशक्त चर के मान को 5 गुना और 123 से एक बार बढ़ा देगा, जिसके बाद यह परिणाम को 10-दशमलव और 16-दशमलव मान के रूप में आउटपुट करेगा। अपेक्षित मान निम्नानुसार होंगे: 128 और 00000080।

मान लीजिए कि कोड एक त्रुटि के साथ लिखा गया है:

var B: Integer = 123; procedure TForm1.FormCreate(Sender: TObject); var A: Integer; begin Inc(A); Inc(A); Inc(A, B); Inc(A); Inc(A); Inc(A); ShowMessage(IntToStr(A)); ShowMessage(IntToHex(A, 8)); end;

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

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

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

यहां तक कि दोनों चर और कोड की तीन पंक्तियों के मूल्यों पर एक त्वरित नज़र, हम समझ सकते हैं कि चर "ए" का मूल्य अपेक्षित से मेल नहीं खाता है। चूँकि प्रति यूनिट दो वेतन वृद्धि और 123 की वृद्धि हुई थी, हमें चर "A" संख्या 125 का मान देखना चाहिए, और चूँकि एक अलग मान है, इसका केवल एक ही मतलब हो सकता है - चर "A" का प्रारंभिक मान नहीं था। सच।

हमारी धारणा की शुद्धता की जांच करने के लिए, हम चर "A" के वर्तमान मान को सही एक में बदलते हैं और प्रक्रिया द्वारा लौटाए गए परिणामों की अपेक्षा की गई थी या नहीं इसकी जाँच करने के लिए कार्यक्रम जारी रखें।

चर के मूल्यों को बदलने के लिए डीबगर में दो उपकरण दिए गए हैं।

पहला - "मूल्यांकन / संशोधित करें", या तो मेनू के माध्यम से या गर्म कुंजी "Ctrl + F7" के माध्यम से कहा जाता है। यह एक बहुत ही सरल उपकरण है जिसमें न्यूनतम कार्यक्षमता होती है, इसका सबसे अधिक उपयोग किया जाता है।

यह इस तरह दिखता है:

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

चर "ए" के मूल्य को बदलने के बाद, स्थानीय चर के मूल्यों की सूची में बदलाव पर ध्यान दें:

चर "ए" ने सही मान लिया है, और अब हम "एफ 9" दबाकर या मेनू के माध्यम से "रन" का चयन करके अपने आवेदन का निष्पादन जारी रख सकते हैं। डिबगर की मदद से इस तरह के हस्तक्षेप के परिणामस्वरूप, प्रक्रिया हमें अपेक्षित संख्या 128 और 00000080 देगी, और हम प्रक्रिया कोड को सुरक्षित रूप से सही कर सकते हैं, क्योंकि हमने इसमें त्रुटि का कारण पाया और चर "ए" के सही मूल्य के साथ इसके निष्पादन की जांच की।

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

यह अधिक "उन्नत" परिवर्तनीय गुण संपादक है, लेकिन वस्तुओं के गुणों को बदलते समय इसका उपयोग उचित है। यह सामान्य चर को बदलने के लिए कुछ असुविधाजनक है, और यहाँ क्यों है।

जब आप इसे कॉल करते हैं, तो आप पहली बार इस संवाद को देखेंगे:

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

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

वस्तु के गुणों के लिए "मूल्यांकन / संशोधित" के माध्यम से कुछ हद तक जटिल है कि यह अध्ययन के तहत वस्तु के बारे में सीधे जानकारी प्रदान नहीं करता है। उदाहरण के लिए, फ़ॉर्म के कैनवस को संभालने के लिए, हमें इसमें निम्न पाठ टाइप करना होगा: “(Sender as TForm1)। Canvas.Handle” - जो कुछ हद तक असुविधाजनक है, क्योंकि हमें सील किया जा सकता है, और यह किसी संपत्ति के नाम को भूलने के लिए बस कॉर्नी है।

निरीक्षण के मामले में, ऐसी कोई समस्या नहीं होगी।

उदाहरण के लिए, चलिए "निरीक्षण" संवाद को '' ए '' के लिए नहीं, बल्कि चर स्व के लिए खोलें (जो, जैसा कि मैंने पहले कहा था, हमेशा सभी वस्तुओं के तरीकों के लिए मौजूद है)।

जैसा कि आप देख सकते हैं, इस मामले में हमारे पास ऑब्जेक्ट के लगभग सभी क्षेत्रों तक पहुंच है, जिसे हम कृपया बदल सकते हैं, और हम गुणों के नाम पर भ्रमित नहीं होंगे।

1.2। ट्रेसिंग (चरण-दर-चरण डिबगिंग)

अनुरेखण का सार कोड की प्रत्येक पंक्ति का चरण-दर-चरण निष्पादन है।

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

और वह निम्नलिखित जानता है:

कमांड "ट्रेस इन" ("F7") - डिबगर कोड की वर्तमान लाइन के कोड को निष्पादित करेगा और अगले पर रोक देगा। यदि कोड की वर्तमान लाइन एक प्रक्रिया को बुलाती है, तो अगली पंक्ति को प्रक्रिया की पहली पंक्ति कहा जाएगा।
"स्टेप ओवर" कमांड ("F8") पहले कमांड के समान है, लेकिन प्रक्रिया के शरीर में कोई प्रविष्टि नहीं होती है।
"ट्रेस टू नेक्स्ट सोर्स लाइन" कमांड ("शिफ्ट + एफ 7") भी पहले कमांड का लगभग पूरा एनालॉग है, लेकिन इसका उपयोग "सीपीयू-व्यू" विंडो में किया जाता है (यह डीबगिंग मोड लेख में नहीं माना जाता है)।
"Run to Cursor" ("F4") कमांड - डीबगर प्रोग्राम कोड को उस लाइन तक निष्पादित करेगा जिस पर कर्सर अब स्थित है (इस शर्त के साथ कि निष्पादन के दौरान कोई अन्य BPs का सामना नहीं किया गया था)।
"रन तक रिटर्न" कमांड ("शिफ्ट + एफ 8") - डिबगर वर्तमान प्रक्रिया के कोड को निष्पादित करेगा जब तक कि यह बाहर नहीं निकलता। (अक्सर गलती से दबाए गए "F7" के लिए एक काउंटर के रूप में उपयोग किया जाता है और इस शर्त के तहत कि निष्पादन के दौरान कोई अन्य बीपी सामना नहीं किया गया था)।
डेल्फी के पुराने संस्करणों में, "सेट नेक्स्ट स्टेटमेंट" कमांड उपलब्ध है, जिसके साथ हम किसी भी कोड को वर्तमान के रूप में सेट करके प्रोग्राम की प्रगति को बदल सकते हैं। यह सुविधा कोड संपादक में भी उपलब्ध है जहां आप वर्तमान सक्रिय लाइन की ओर इशारा करते हुए तीर को नई स्थिति में खींच सकते हैं।

इन टीमों को विस्तृत विचार की आवश्यकता नहीं है। हमें केवल "ट्रेस इन" ("F7") टीम पर ध्यान दें।

उदाहरण के लिए, निम्नलिखित कोड लें:

 procedure TForm1.FormCreate(Sender: TObject); var S: TStringList; begin S := TStringList.Create; try S.Add('My value'); finally S.Free; end; end;

ट्रेसिंग करते समय, उस समय जब हम S.Add () लाइन पर होते हैं, हमारे पास डीबगर के लिए दो विकल्प हो सकते हैं:

हम TStringList.dd विधि के अंदर जाएंगे,
हमने वहां प्रवेश नहीं किया।

यह व्यवहार आपके कंपाइलर की सेटिंग के कारण होता है। तथ्य यह है कि डेल्फी जहाजों को सिस्टम मॉड्यूल के लिए डीसीयू के दो सेट के साथ। एक डिबग जानकारी के साथ, दूसरा बिना। यदि हमारे पास दूसरा मॉड्यूल जुड़ा हुआ है, तो इस मामले में "ट्रेस इन्टो" ("एफ 7") कमांड "स्टेप ओवर" ("एफ 8") के रूप में काम करेगा। संकलक सेटिंग्स में मॉड्यूल के बीच स्विच करना कॉन्फ़िगर किया गया है:

और "कार्यक्षमता का उपयोग करें डीबग DCUs" पैरामीटर इस कार्यक्षमता के लिए जिम्मेदार है।

1.3। संकलक सेटिंग्स पर अधिक

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

आइए उन पर अधिक विस्तार से विचार करें:

कोड पीढ़ी समूह

अनुकूलन पैरामीटर

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

एक उदाहरण के रूप में, पहले अध्याय से कोड लें और उसी बीपी पर ध्यान दें, लेकिन अनुकूलन चालू होने पर।

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

स्टैक फ्रेम्स और पेंटिओम-सुरक्षित एफडीआईवाई विकल्प

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

रिकॉर्ड फ़ील्ड संरेखण पैरामीटर

अनपैक्ड रिकॉर्ड्स का वैश्विक संरेखण, जिसे "{$ संरेखित करें}" या "{$ A x}" निर्देश का उपयोग करके मॉड्यूल के भीतर स्थानीय रूप से बदला जा सकता है।

उदाहरण के लिए, निम्नलिखित कोड पर विचार करें:

 type T = record a: Int64; b: Byte; c: Integer; d: Byte; end;

इस रिकॉर्ड का आकार, जिसे हम SizeOf (T) के माध्यम से प्राप्त कर सकते हैं, प्रत्येक संरेखण सेटिंग्स के लिए अलग होगा:

{$ संरेखित करें १} = १४
{$ संरेखित करें २} = १६
{$ संरेखित करें ४} = २०
{$ संरेखित करें 8} = २४

सिंटैक्स विकल्प समूह

कुछ भी नहीं छूना बेहतर है। यदि आप कोशिश करते हैं, तो आप मानक वीसीएल को इकट्ठा करने से मना भी कर सकते हैं।

मैं केवल "पूरा बॉलेन एवल" पैरामीटर पर रहूंगा, क्योंकि समय-समय पर उनमें से कुछ इसे चालू करते हैं। यह निम्नलिखित कोड को निष्पादित करते समय एक त्रुटि का सामना करता है:

 function IsListDataPresent(Value: TList): Boolean; begin Result := (Value <> nil) and (Value.Count > 0); end; procedure TForm1.FormCreate(Sender: TObject); begin if IsListDataPresent(nil) then ShowMessage('boo...'); end;

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

रनटाइम त्रुटियाँ समूह

रेंज चेकिंग पैरामीटर

किसी एप्लिकेशन को डीबग करते समय यह सबसे अनुरोधित मापदंडों में से एक है। वह डेटा ऐरे तक पहुँचने के दौरान सीमाओं की जाँच के लिए जिम्मेदार है।

सरलतम स्थिति में, जब आप इस कोड को निष्पादित करेंगे तो एक अपवाद रखा जाएगा:

 const A: array [0..1] of Char = ('A', 'B'); procedure TForm1.FormCreate(Sender: TObject); var I: Integer; begin for I := 0 to 100 do Caption := Caption + A[I]; end;

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

जो कार्यक्रम के निष्पादन के लिए अप्रिय, लेकिन राजनीतिक नहीं है। यह बहुत बुरा है अगर आपने इसे लिखने की कोशिश करते समय ब्लॉक की सीमाओं के साथ गलती की - इस मामले में, एप्लिकेशन मेमोरी नष्ट हो सकती है।

इस उदाहरण पर विचार करें, अनुकूलन अक्षम करें:

 type TMyEnum1 = (en1, en2, en3, en4, en5); TMyEnum2 = en1..en3; procedure TForm1.FormCreate(Sender: TObject); var I: TMyEnum1; HazardVariable: Integer; Buff: array [TMyEnum2] of Integer; begin HazardVariable := 100; for I := Low(I) to High(I) do Buff[I] := Integer(I); ShowMessage(IntToStr(HazardVariable)); end;

आपको क्या लगता है कि इस कोड के निष्पादन के बाद HazardVariable संख्या का मूल्य क्या होगा? नहीं, 100 नहीं। यह 4 होगा। चूँकि हमने पुनरावृत्ति के प्रकार का चयन करते समय एक गलती की और TMyEnum2 के बजाय TMyEnum1 लिखा, सरणी की सीमाओं की सीमा पार हो गई थी और स्टैक पर डेटा खो गया था, इस पर संग्रहीत स्थानीय चर के मूल्यों को बदल दिया।

अनुकूलन सक्षम होने से स्थिति और भी खराब होगी। हमें निम्नलिखित त्रुटि मिलती है:

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

इसलिए, इसे एक नियम के रूप में लें - एप्लिकेशन डिबगिंग हमेशा "रेंज चेकिंग" सेटिंग चालू होने के साथ होनी चाहिए!

इसके अलावा, यह पैरामीटर चर के मूल्य को बदलते समय अनुमेय मूल्यों की अधिकता को नियंत्रित करता है। उदाहरण के लिए, कार्डिनल / DWORD जैसे अहस्ताक्षरित प्रकारों के लिए एक नकारात्मक मान निर्दिष्ट करने का प्रयास करते समय एक अपवाद उठाया जाएगा, या जब इस प्रकार के एक चर से अधिक मान निर्दिष्ट करने का प्रयास किया जा सकता है, उदाहरण के लिए, जब प्रकार के 500 के बाइट को असाइन करना, आदि।

पैरामीटर "आई / ओ चेकिंग"

यह पास्कल शैली में फ़ाइलों के साथ काम करते समय I / O परिणामों की जांच करने के लिए जिम्मेदार है।

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

अतिप्रवाह चेकिंग विकल्प

यह अंकगणित संचालन के परिणामों को नियंत्रित करता है और उन मामलों में अपवाद को बढ़ाता है जहां परिणाम चर की सीमा के बाहर है।

इस पैरामीटर और "रेंज जाँच" के बीच के अंतरों को समझना आसान बनाने के लिए, निम्नलिखित कोड पर विचार करें:

 procedure TForm1.FormCreate(Sender: TObject); var C: Cardinal; B: Byte; I: Integer; begin I := -1; B := I; C := I; ShowMessage(IntToStr(C - B)); end;

जब "अतिप्रवाह चिंगारी" विकल्प सक्षम होता है तो यह कोड अपवाद नहीं उठाएगा। हालांकि अस्वीकार्य मान यहां चर के लिए असाइन किए गए हैं, उन पर कोई गणितीय कार्य नहीं किया जाता है। हालाँकि, "सीमा जाँच" विकल्प सक्षम होने पर एक अपवाद उठाया जाएगा।

अब कोड के दूसरे संस्करण पर विचार करें:

 procedure TForm1.FormCreate(Sender: TObject); var C: Cardinal; B: Byte; begin B := 255; Inc(B); C := 0; C := C - 1; ShowMessage(IntToStr(C - B)); end;

"रेंज चेकिंग" पैरामीटर से अब कोई प्रतिक्रिया नहीं होगी, लेकिन एक EIntegerOverflow अपवाद उठाया जाएगा, जो "ओवरफ्लो चीकिंग" लाइनों के लिए जिम्मेदार है, इंक (B) और C: = C - 1 इस तथ्य के कारण कि अंकगणितीय ऑपरेशन का परिणाम नहीं हो सकता है इसी चर में संग्रहीत किया जाना चाहिए।
इस प्रकार, जब चर के साथ काम करते हैं, तो दोनों पैरामीटर एक दूसरे के पूरक होते हैं।

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

एक छोटी सी बारीकियों: यदि आप अचानक क्रिप्टोग्राफिक एल्गोरिदम को लागू करते हैं, तो उनमें, एक नियम के रूप में, अतिप्रवाह ऑपरेशन मानक है। ऐसी स्थितियों में, कोड को एक अलग मॉड्यूल में स्थानांतरित करें और वर्तमान मॉड्यूल में ओवरफ्लो जाँच को अक्षम करने के लिए मॉड्यूल की शुरुआत में "{$ OVERFLOWCHECKS OFF}" लिखें।

डिबगिंग समूह

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

सारांश।

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

1.4। स्टैक विंडो को कॉल करें

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

यह खिड़की इस प्रकार है:

इसमें उन कॉल का पूरा विवरण होता है, जो डीबगर स्थापित बीपी पर प्रोग्राम के निष्पादन में बाधा डालने से पहले किए गए थे (या एक त्रुटि के कारण बंद हो गए)। उदाहरण के लिए, स्क्रीनशॉट कॉल का एक स्टैक दिखाता है, जब आपने फॉर्म पर एक बटन क्लिक किया था। यह TW_Control.DefaultHandler प्रक्रिया में WM_COMMAND (273) संदेश के आगमन के साथ शुरू हुआ।

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

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

उदाहरण के लिए, जब कोई ईब्रेट एरर त्रुटि होती है तो कॉल स्टैक इस तरह दिखाई देगा:

इस मामले में, ऊपर से बहुत पहले कॉल को खोजने के लिए पर्याप्त है, जिनमें से कोड डेल्फी सिस्टम मॉड्यूल में स्थित नहीं है, ताकि उच्च स्तर की संभावना के साथ यह कह सके कि त्रुटि इसमें है। ऐसी कॉल Unit1.TForm1.Button1Click () है - यह Button1 बटन हैंडलर है जिसमें निम्नलिखित कोड निष्पादित किया गया था:

 procedure TForm1.Button1Click(Sender: TObject); begin TStrings.Create.Add('qwe'); end;

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

मॉड्यूल पर जाएं जहां हमारे लिए ब्याज की फ़ंक्शन की कॉल घोषित की गई है (इस मामले में, windows.pas),
इसकी घोषणा (एक नीले डॉट फ़ंक्शन मैसेजबॉक्स के साथ लाइन; बाहरी user32 ...) खोजें;
इस लाइन पर बीपी स्थापित करें और प्रोग्राम चलाएं।

जैसे ही प्रोग्राम में कहीं से एक मैसेजबॉक्स कॉल किया जाता है, हमारा बीपी काम करेगा और हम कॉल स्टैक डेटा के आधार पर, इसके कॉल की सही जगह का पता लगाने में सक्षम होंगे।

1.5। उन्नत ब्रेकपॉइंट गुणों के साथ काम करना

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

यह ब्रेकपॉइंट गुणों के लिए सेटिंग संवाद के माध्यम से किया जाता है। इसे एप्लिकेशन कोड में BP संपत्तियों के माध्यम से या तो कहा जाता है।

या ब्रेकपॉइंट सूची विंडो में भी चयनित बीपी के गुणों के माध्यम से।

सेटिंग्स संवाद इस तरह दिखता है:

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

एक सार उदाहरण पर विचार करें:

 procedure TForm1.FormCreate(Sender: TObject); var I, RandomValue: Integer; begin RandomValue := Random(100); for I := 1 to 100 do RandomValue := RandomValue + I; ShowMessage(IntToStr(RandomValue)); end;

मान लीजिए कि बीपी सातवीं पंक्ति (रैंडमवैल्यू: = ...) पर स्थापित है। यदि कार्यक्रम चलाना आसान है, तो हम हाथ पर ठीक 100 बीपी संचालन प्राप्त करते हैं। इस बीपी के लिए हर दसवें कॉल पर काम करने के लिए, आपको "पास काउंट" प्रॉपर्टी में मान 10 सेट करने की आवश्यकता है। इस मामले में, हमें ठीक दस बीपी ऑपरेशन मिलेंगे, उस समय कोड इटेटर "I" दस में से कई होगा।

मान लें कि हम 75 पुनरावृत्तियों को सम्मिलित करने के बाद विश्लेषण शुरू करना चाहते हैं, इसके लिए हम "कंडीशन" पैरामीटर में निम्न शर्त सेट करते हैं: I> 75। इस मामले में, यह बीपी केवल दो बार काम करेगा: उस समय जब इट्रेटर "I" 85 है, और दूसरी बार, 95 के मान के साथ। यह

निम्नलिखित कारणों से हुआ:

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

दूसरे मामले में, प्रारंभिक स्थिति "कंडीशन" पूरी होने के बाद ही यात्राओं के काउंटर में वृद्धि शुरू हुई, यानी, इट्रेटर "I" संख्या 75 से कम या उसके बराबर था, डीबगर ने माना कि शर्त पूरी नहीं हुई और कार्यक्रम जारी रखा। जैसे ही पहली शर्त पूरी हो जाती है, यात्रा की संख्या में वृद्धि शुरू हो गई, जो उस समय "पास गणना" पैरामीटर के मूल्य के बराबर हो गई, जब इट्रेटर "I" 85 पर पहुंच गया।

स्वाभाविक रूप से, यदि हम चाहते हैं कि बीपी इट्रेटर के तुरंत बाद काम करना शुरू कर दे "I "संख्या 75 में से, फिर पैरामीटर" पास गणना "को शून्य पर सेट किया जाना चाहिए।

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

अब एक छोटी सी बारीकियों पर विचार करें।

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

यह क्यों खराब है: यदि आप इस तरह से पर्याप्त लंबे चक्र का विश्लेषण करते हैं (उदाहरण के लिए, दस हजार पुनरावृत्तियों और ऊपर से), तो प्रोग्राम को डीबग करना आपके काम को बहुत धीमा कर सकता है।

आप निम्न कोड पर जाँच कर सकते हैं:

 procedure TForm1.FormCreate(Sender: TObject); var I, RandomValue: Integer; begin RandomValue := Random(100); for I := 1 to 10000 do RandomValue := RandomValue + I; ShowMessage(IntToStr(RandomValue)); end;

बीपी को उसी सातवीं पंक्ति पर सेट करें और पैरामीटर "शर्त" में निर्दिष्ट करें I = 9999। यहां तक कि इस तरह के एक छोटे से चक्र पर, हमें 3-5 सेकंड के क्षेत्र में काम करने के लिए स्थिति का इंतजार करना होगा। बेशक, यह सुविधाजनक नहीं है। ऐसे मामलों में, कोड को संशोधित करना आसान है:

 procedure TForm1.FormCreate(Sender: TObject); var I, RandomValue: Integer; begin RandomValue := Random(100); for I := 1 to 10000 do begin RandomValue := RandomValue + I; {$IFDEF DEBUG} if I = 9999 then Beep; {$ENDIF} end; ShowMessage(IntToStr(RandomValue)); end;

... और बीपी को बीपी पर रखो, इतने लंबे समय तक प्रतीक्षा करें। इस मामले में, हमें लगभग तुरंत नियंत्रण मिलेगा।
(परियोजना के रिलीज़ बिल्ड में कोई DEBUG निर्देश नहीं होगा और डिबगिंग कोड इसमें नहीं मिलेगा, लेकिन यह डीबगिंग के बाद बेहतर है, इन सभी डीबगिंग Beeps को हटाने के लिए याद रखना।)

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

 function Test1(var Value: Integer): Cardinal; var I: Integer; begin Result := GetTickCount; for I := 1 to 100000000 do Inc(Value); Result := GetTickCount - Result; end; function Test2(var Value: Integer): Cardinal; var I: Integer; begin Result := GetTickCount; for I := 1 to 100000000 do try Inc(Value); finally end; Result := GetTickCount - Result; end; procedure TForm1.FormCreate(Sender: TObject); var A: Integer; begin A := 0; ShowMessage(IntToStr(Test1(A))); A := 0; ShowMessage(IntToStr(Test2(A))); end;

Test1 और Test2 के कार्यों में, संचरित मूल्य 100 मिलियन बार बढ़ाया जाता है।

पहले मामले में, यह 210 मिलीसेकंड के क्षेत्र में चलता है, जबकि दूसरे मामले में यह साढ़े चार गुना लंबा है, और वास्तव में उनके बीच कोई बदलाव नहीं है - यह सिर्फ एक सुस्त कोशिश है..बस।

यह, वैसे, आपके "गुल्लक" में भी है - यदि संभव हो तो, लूप के अंदर अपवाद हैंडलिंग सम्मिलित न करें, इसे सीमा से बाहर ले जाना बेहतर है ...

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

समूह संचालन को उन्नत बीपी

सेटिंग्स में कॉन्फ़िगर किया गया है : इसके लिए पैरामीटर जिम्मेदार हैं: "समूह सक्षम करें" - सभी बीपी समूहों को सक्रिय करना, और "समूह अक्षम करें" - समूह में शामिल सभी बीपी को अक्षम करना।

इसके अलावा, समूह संचालन में, "ब्रेक" पैरामीटर का उपयोग अक्सर किया जाता है, जो डीपी तक पहुंचने पर डीबगर की क्रियाओं के लिए जिम्मेदार होता है। यदि यह पैरामीटर सक्रिय नहीं है, तो इस बीपी तक पहुंचने पर प्रोग्राम निष्पादन में व्यवधान उत्पन्न नहीं होता है।
महत्वपूर्ण - यह विकल्प स्वयं बीपी को अक्षम नहीं करता है।

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

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

उदाहरण को संकलित करने से पहले, संकलक सेटिंग्स में "अतिप्रवाह चेकिंग" विकल्प को सक्षम करना सुनिश्चित करें और अनुकूलन को अक्षम करें।

 function Level3(Value: Integer): Integer; var I: Integer; begin Result := Value; for I := 0 to 9 do Inc(Result); end; function Level2(Value: Integer): Integer; var I: Integer; begin Result := Value; for I := 0 to 9 do Inc(Result, Level3(Result) shr 1); end; function Level1(Value: Integer): Integer; var I: Integer; begin Result := Value; for I := 0 to 9 do Inc(Result, Level2(Result) shr 3); end; procedure TForm1.FormCreate(Sender: TObject); begin ShowMessage(IntToStr(Level1(0))); end;

इस कोड को चलाने के बाद, सोलहवीं पंक्ति पर एक अपवाद उत्पन्न होगा

 Inc(Result, Level3(Result) shr 1);.

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

डिबगिंग की प्रक्रिया में, एप्लिकेशन आमतौर पर कई बार पुनरारंभ होता है, और डीबग करने के लिए इसे सुविधाजनक बनाने के लिए, हमें इस लाइन पर बीपी स्थापित करने की आवश्यकता है ताकि यह त्रुटि से पहले तुरंत काम करे।

इसे निम्नानुसार करते हैं:

हम बीपी को सोलहवीं पंक्ति में रखते हैं और समूह को "Level2BP" पर असाइन करते हैं।
, . FormCreate ShowMessage «Disable group» «level2BP». , «Break».
Level1 №25. , .
, 9 ( I ). , 8 , , «level2BP». «Condition» I=8, «Break» «Enable group» «level2BP».
, Level2, – . F9, , , , I 5. «Condition» I=5, .
, .

यदि उदाहरण के वर्णन से सब कुछ स्पष्ट नहीं है, तो क्रियाओं के पूरे अनुक्रम को प्रदर्शित करने वाले वीडियो को देखें:
rouse.drkb.ru/blog/bp3.mp4 (17 एमबी)।
(मुझे खेद है, लेकिन मैं लिंक डालने में सफल नहीं हुआ, ताकि वीडियो सीधे लेख के मुख्य भाग में दिखाई दे, इसलिए, केवल लिंक)

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

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

यह कुछ और मापदंडों पर विचार करने के लिए बना हुआ है।

"बाद के अपवादों को अनदेखा करें" पैरामीटर किसी भी अपवाद के लिए डीबगर की प्रतिक्रिया को निष्क्रिय कर देता है जो बीपी को निष्पादित करने के बाद होता है जो इस पैरामीटर को सक्षम करता है।

"बाद के अपवादों को हैंडल करें" पैरामीटर पिछले पैरामीटर को रद्द कर देता है, डिबगर को सामान्य ऑपरेशन मोड में लौटाता है।

यह कैसे दिखता है यह देखने के लिए, निम्न कोड बनाएं:

 procedure TForm1.Button1Click(Sender: TObject); begin ShowMessage('All exceptions ignored'); end; procedure TForm1.Button2Click(Sender: TObject); begin PInteger(0)^ := 123; end; procedure TForm1.Button3Click(Sender: TObject); var S: TStrings; begin S := TStrings.Create; try S.Add('abstract') finally S.Free; end; end; procedure TForm1.Button4Click(Sender: TObject); begin ShowMessage('All exceptions handled'); end;

पहले ShowMessage पर, BP सेट करें, "ब्रेक" पैरामीटर को अनचेक करके इसे बंद करें, और "बाद के अपवादों को अनदेखा करें" पैरामीटर को चालू करें।

दूसरे ShowMessage पर भी ऐसा ही करें, बस "बाद के अपवादों को संभालें" पैरामीटर को सक्षम करें।

डिबगर से एप्लिकेशन लॉन्च करें और निम्नलिखित क्रम में बटन पर क्लिक करें:

Button1
Button2
Button3
Button4
Button2
Button3

इस तथ्य के बावजूद कि बटन 2 और बटन 3 बटन एक अपवाद उत्पन्न करते हैं, चरण 2 और 3 पर डिबगर किसी भी तरह से उन पर प्रतिक्रिया नहीं करेगा, हम बटन 5 बटन दबाकर सामान्य अपवाद हैंडलिंग को सक्रिय करने के बाद केवल 5 और 6 चरणों में प्रतिक्रिया से इंतजार करेंगे।

2 पैरामीटर बचे हैं:

"लॉग संदेश" - कोई भी टेक्स्ट लाइन जो बीपी तक पहुंचने पर ईवेंट लॉग में प्रदर्शित होगी।

"एवल एक्सप्रेशन" - बीपी तक पहुंचने पर, डिबगर इस पैरामीटर के मान की गणना करता है और (यदि "लॉग परिणाम" ध्वज सक्षम है) तो इसे इवेंट लॉग में प्रदर्शित करता है। गणना के लिए मूल्य कोई भी हो सकता है, कम से कम समान "123 * 2"।

1.6। डेटा ब्रेकपॉइंट, वॉच लिस्ट और कॉल स्टैक का उपयोग करना

सब कुछ जिसे हम पहले मानते थे, तथाकथित "स्रोत ब्रेकपॉइंट" के थे। यही है, सीधे एप्लिकेशन कोड में सेट किए गए ब्रेकपॉइंट्स के लिए।

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

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

परेशानी यह है कि इस मूल्य को प्राप्त करना इस तथ्य के कारण काफी कठिन है कि हर बार आवेदन शुरू होने पर, जिस पते पर चर स्थित है वह हर बार अलग होगा।

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

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

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

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

निम्नलिखित कोड पर विचार करें:

 type TTest = class Data: array [0..10] of Char; Caption: string; Description: string; procedure ShowCaption; procedure ShowDescription; procedure ShowData; end; TForm1 = class(TForm) procedure FormCreate(Sender: TObject); private FT: TTest; procedure InitData(Value: PChar); end; var Form1: TForm1; implementation {$R *.DFM} { TTest } procedure TTest.ShowCaption; begin ShowMessage(Caption); end; procedure TTest.ShowData; begin ShowMessage(PChar(@Data[0])); end; procedure TTest.ShowDescription; begin ShowMessage(Description); end; { TForm1 } procedure TForm1.FormCreate(Sender: TObject); begin FT := TTest.Create; try FT.Caption := 'Test caption'; FT.Description := 'Test Description'; InitData(@FT.Data[0]); FT.ShowCaption; FT.ShowDescription; FT.ShowData; finally FT.Free; end; end; procedure TForm1.InitData(Value: PChar); const ValueData = 'Test data value'; var I: Integer; begin for I := 1 to Length(ValueData) do begin Value^ := ValueData[I]; Inc(Value); end; end;

पहली नज़र में, सब कुछ सही प्रतीत होता है, लेकिन जब हम प्रोग्राम चलाते हैं तो हमें कुछ इस तरह मिलेगा:

"ब्रेक" पर क्लिक करके, हम "सिस्टम" मॉड्यूल के अंदर कहीं खुद को पाएंगे:

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

इसका मतलब है कि कहीं न कहीं स्मृति भ्रष्टाचार था और कैप्शन चर के पते पर डेटा खो गया था। "डेटा ब्रेकप्वाइंट" हमें इस स्थान को निर्धारित करने में मदद करेगा।

Caption, FT.Description := 'Test Description';.
, FP.Caption «Watch List» «Break When Changed». (, Delphi 2010 ), «Data breakpoint» . «Breakpoint List» «Add->Data Breakpoint», FP.Caption .
.

इन चरणों को पूरा करने के बाद, कार्यक्रम लाइन नंबर 68 पर बंद हो जाएगा - इंक (मूल्य)। "डेटा ब्रेकपॉइंट" की ख़ासियत यह है कि यह परिवर्तन होने के तुरंत बाद ही होता है, और नियंत्रित मेमोरी को बदलने की कोशिश करते समय नहीं, इसलिए एफपी के पते पर रिकॉर्डिंग के स्थान पर होने वाली जगह ऊपर की रेखा पर स्थित होती है - यह पंक्ति मान है: = ValueData [I ]।

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

1.7। निष्कर्ष में

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

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

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

डिबगर सीखना, भाग एक