2009-07-01 8 views
6

का कारण निर्धारित करें हमारे पास नोडेटर्मिनिस्टिक सिस्टम है। मूल कोड से एक्सेवियोशन अपवाद। इसे पुन: उत्पन्न करना मुश्किल है, लेकिन कभी-कभी ऐसा होता है। मुझे यकीन नहीं है कि अगर मैं एक्सेस उल्लंघन के लिए आवश्यक समय के बारे में 2 घंटे तक "बस इसे डीबग कर सकता हूं" और इस बात की कोई गारंटी नहीं है कि उल्लंघन का उल्लंघन होगा।System.AccessViolationException

देशी पुस्तकालय का उपयोग प्रबंधित रैपर द्वारा किया जाता है। इसका उपयोग जावा से जेएनआई के माध्यम से किया जाता है और इसका उपयोग .NET से IKVM'ed जेएनआई के माध्यम से किया जाता है। समस्या केवल IKVM'ed कोड के दौरान पुन: उत्पन्न की गई थी, लेकिन डेटा सेट अलग है और जावा एप्लिकेशन को IKVM'ed एप्लिकेशन द्वारा उपयोग किए जाने वाले डेटा के साथ परीक्षण करने का कोई तरीका नहीं है।

मेरे पास सब कुछ के लिए स्रोत हैं, लेकिन (यदि संभव हो) मैं बड़ी संख्या में बदलाव करने से बचना चाहता हूं।

मेरा मानना ​​है कि देशी कॉल स्टैक इस एक्सेस उल्लंघन के कारण के बारे में पर्याप्त जानकारी प्रदान करेगा।

क्या इस पहुंच उल्लंघन के कारण का निर्धारण करने का कोई प्रभावी तरीका है?

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

उत्तर

2

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

+0

एचएम .. मैंने अपना मूल कोड बदल दिया है, इसलिए निश्चित रूप से इसका उपयोग उल्लंघन हो गया है और इसे डीबग प्रतीकों के साथ पुन: संकलित किया गया है। जब मैंने सामान्य रूप से प्रक्रिया शुरू की और विजुअल स्टूडियो डीबगर संलग्न किया। मैंने AccessViolationException को फेंकने के लिए ब्रेकपॉइंट जोड़ा है, लेकिन यह कैच नहीं किया गया था। कोई सुझाव? – okutane

+1

ठीक है, मुझे पता चला है कि ब्रेकपॉइंट Win32 एक्सेस उल्लंघन होना चाहिए। – okutane