एक्सेस उल्लंघन उल्लंघन त्रुटियों को डीबग करना?

Question

डेल्फी में एप्लिकेशन लिखते समय एक्सेस उल्लंघनों का पता लगाने और ठीक करने में सहायता के लिए आप कौन सी युक्तियां साझा कर सकते हैं?

मेरा मानना ​​है कि एक्सेस उल्लंघन आमतौर पर स्मृति में कुछ एक्सेस करने का प्रयास करके होता है जिसे अभी तक ऑब्जेक्ट आदि जैसे नहीं बनाया गया है?

मुझे यह पता लगाना मुश्किल लगता है कि एक्सेस उल्लंघनों को किस प्रकार ट्रिगर करता है और फिर आवश्यक परिवर्तन करने के लिए कहां प्रयास करें और उन्हें रोकें।

एक उदाहरण एक निजी परियोजना है जिसे मैं अभी काम कर रहा हूं। मैं TTreeView नोड में संग्रहीत कर रहा हूं। डेटा प्रत्येक नोड के लिए कुछ डेटा संपत्ति। नोड्स को कई चयनित और निर्यात किया जा सकता है (निर्यात प्रत्येक चयनित नोड के माध्यम से पुनरावृत्त करता है और टेक्स्ट फ़ाइल में विशिष्ट डेटा सहेजता है - पाठ फ़ाइल में सहेजी गई जानकारी nodes.data में संग्रहीत होती है)। फ़ाइलों को ट्रीव्यू में भी आयात किया जा सकता है (टेक्स्ट फ़ाइलों की सामग्री को node.data में सहेजना)।

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

"पता 00,405,772 पर पहुँच उल्लंघन मॉड्यूल 'Project1.exe' में पता 00000388. की पढ़ें।"

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

मैं उपर्युक्त उदाहरण के लिए एक फिक्स की तलाश नहीं कर रहा हूं, लेकिन मुख्य रूप से सलाह/युक्तियाँ कि इस प्रकार की त्रुटियों को कैसे ढूंढें और ठीक करें। मुझे अक्सर एक्सेस उल्लंघन नहीं मिलता है, लेकिन जब मैं करता हूं तो उन्हें ट्रैक करना और ठीक करना मुश्किल होता है।

तो सलाह और सुझाव बहुत उपयोगी होंगे।

Answer 1

इसका मतलब है कि आपका कोड उस स्मृति के कुछ भाग तक पहुंच रहा है जिसकी अनुमति नहीं है। आमतौर पर इसका मतलब है कि आपके पास गलत स्मृति को इंगित करने वाला पॉइंटर या ऑब्जेक्ट संदर्भ है। शायद क्योंकि यह प्रारंभ नहीं हुआ है या पहले से ही जारी किया गया है।

डेल्फी जैसे डीबगर का उपयोग करें। यह आपको बताएगा कि एवी की किस पंक्ति में कोड आया था। वहां से कॉलस्टैक और स्थानीय चर आदि को देखकर आपकी समस्या का पता लगाएं। कभी-कभी यह डीबग डीसीयू के साथ संकलित होने पर भी मदद करता है।

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

कुछ ऐसे उपकरण हैं जो अधिक आक्रामक तरीके से जांच कर इस तरह की समस्याओं को ढूंढने में सक्षम हो सकते हैं। फास्टएमएम मेमोरी मैनेजर के पास ऐसे विकल्प हैं।

संपादित

"प्रवेश मॉड्यूल में पता 00,405,772 'Project1.exe'। पता 00000388. की पढ़ें पर उल्लंघन"

तो आपकी समस्या मॉड्यूल 'Project1.exe' में 00405772 पते पर एवी में परिणाम देती है। डेल्फी डीबगर आपको कोड की सही रेखा पर लाएगा (या त्रुटि खोजें का उपयोग करें)।

यह पता 00000388 पर स्मृति को पढ़ने की कोशिश कर रहा है। यह 00000000 (शून्य) के करीब है, इसलिए शायद इसका मतलब है कि किसी संकेतक या गतिशील सरणी के संदर्भ में कुछ पॉइंटर/संदर्भ का उपयोग करना होगा। यदि यह बाइट्स की सरणी थी, तो यह आइटम 388 होगा। या यह कई जगहों के साथ एक बड़ी वस्तु या रिकॉर्ड का क्षेत्र हो सकता है। ऑब्जेक्ट या रिकॉर्ड पॉइंटर/संदर्भ शून्य होगा।

Answer 2

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

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

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

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

Answer 3

मैं एक और टूल का उल्लेख करना चाहता हूं, जिसका उपयोग मैं अन्य उपकरणों को एवी का पता लगाने में असफल होने पर उपयोग करता हूं। यह SafeMM (newer version) है। एक बार यह मुझे छोटी 5 लाइन प्रक्रिया के लिए इंगित किया। और मुझे वहां होने वाले एवी को देखने के लिए, इसमें 10 मिनट से अधिक समय लगना पड़ा। शायद उस दिन मेरे प्रोग्रामिंग कौशल उनके अधिकतम नहीं थे, लेकिन आप जानते हैं, इस तरह के दिनों में बुरी चीज ठीक होती है।