खोज…


दुर्घटना के बारे में जानकारी प्राप्त करना

जब आपका ऐप क्रैश हो जाता है, तो Xcode डिबगर में प्रवेश करेगा और आपको क्रैश के बारे में अधिक जानकारी दिखाएगा:

यहाँ छवि विवरण दर्ज करें

सबसे महत्वपूर्ण भाग हैं:

लाल तीर

लाल तीर प्रदर्शित करता है कि कोड की कौन सी पंक्ति दुर्घटनाग्रस्त हो गई और यह दुर्घटनाग्रस्त क्यों हुई।

डीबगर कंसोल

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

ढेर का निशान

स्टैक ट्रेस उन फ़ंक्शनों को सूचीबद्ध करता है जो प्रोग्राम उस कोड से आए थे जो क्रैश हो गया था।

स्टैक ट्रेस का एक हिस्सा स्क्रीन के बाईं ओर डिबग नेविगेटर में प्रदर्शित होता है, और डीबगर नियंत्रण आपको डीबगर में देखने के लिए स्टैक फ़्रेम का चयन करने की अनुमति देता है:

यहाँ छवि विवरण दर्ज करें

यदि आप डीबगर में (lldb) प्रॉम्प्ट पर bt कमांड दर्ज करते हैं और रिटर्न को दबाते हैं , तो आपको स्टैक ट्रेस का एक (lldb) प्रतिनिधित्व मिलेगा जिसे आप कॉपी और पेस्ट कर सकते हैं:

(lldb) bt
* thread #1: tid = 0x3aaec5, 0x00007fff91055f06 libsystem_kernel.dylib`__pthread_kill + 10, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
    frame #0: 0x00007fff91055f06 libsystem_kernel.dylib`__pthread_kill + 10
    frame #1: 0x000000010008142d libsystem_pthread.dylib`pthread_kill + 90
    frame #2: 0x00007fff96dc76e7 libsystem_c.dylib`abort + 129
    frame #3: 0x00007fff8973bf81 libc++abi.dylib`abort_message + 257
    frame #4: 0x00007fff89761a47 libc++abi.dylib`default_terminate_handler() + 267
    frame #5: 0x00007fff94f636ae libobjc.A.dylib`_objc_terminate() + 103
    frame #6: 0x00007fff8975f19e libc++abi.dylib`std::__terminate(void (*)()) + 8
    frame #7: 0x00007fff8975ec12 libc++abi.dylib`__cxa_throw + 121
    frame #8: 0x00007fff94f6108c libobjc.A.dylib`objc_exception_throw + 318
    frame #9: 0x00007fff8d067372 CoreFoundation`-[__NSPlaceholderArray initWithObjects:count:] + 290
    frame #10: 0x00007fff8d0eaa1f CoreFoundation`+[NSArray arrayWithObject:] + 47
  * frame #11: 0x0000000100001b54 test`main(argc=1, argv=0x00007fff5fbff808) + 68 at main.m:15
    frame #12: 0x00007fff8bea05ad libdyld.dylib`start + 1
    frame #13: 0x00007fff8bea05ad libdyld.dylib`start + 1

डिबगिंग SIGABRT और EXC_BAD_INSTRUCTION क्रैश

एक SIGABRT या एक EXC_BAD_INSTRUCTION का आमतौर पर मतलब होता है कि ऐप जानबूझकर दुर्घटनाग्रस्त हो गया क्योंकि कुछ जाँच विफल हो गई। इन्हें अधिक जानकारी के साथ डीबगर कंसोल पर संदेश लॉग करना चाहिए; अधिक जानकारी के लिए वहाँ जाँच करें।

कई SIGABRT s, बिना किसी ऑब्जेक्टिव-सी अपवाद के कारण होते हैं। वहाँ कारणों अपवाद फेंक दिया जा सकता है की एक बहुत हैं, और वे हमेशा कंसोल के लिए उपयोगी जानकारी का एक बहुत प्रवेश करेंगे।

  • NSInvalidArgumentException , जिसका अर्थ है कि ऐप ने एक विधि के लिए एक अमान्य तर्क पारित किया है
  • NSRangeException , जिसका अर्थ है कि ऐप किसी NSArray या NSString जैसी किसी ऑब्जेक्ट के आउट-ऑफ- NSRangeException तक पहुंचने का प्रयास करता है
  • NSInternalInconsistencyException अर्थ है एक ऐसी वस्तु की खोज करना जो अप्रत्याशित अवस्था में थी।
  • NSUnknownKeyException आमतौर पर मतलब है कि आपका XIB में खराब संबंध है। इस प्रश्न के उत्तर में से कुछ का प्रयास करें।

EXC_BAD_ACCESS को डीबग करना

EXC_BAD_ACCESS अर्थ है कि प्रक्रिया ने अमान्य तरीके से मेमोरी को एक्सेस करने की कोशिश की, जैसे NULL पॉइंटर को डीरेफर करना या केवल-पढ़ने के लिए लिखना। यह डीबग करने के लिए क्रैश का सबसे कठिन प्रकार है, क्योंकि इसमें आमतौर पर त्रुटि संदेश नहीं होता है, और कुछ क्रैश को पुन: उत्पन्न करना और / या कोड में समस्या के लिए पूरी तरह से असंबंधित होना बहुत मुश्किल हो सकता है। स्विफ्ट में यह त्रुटि बहुत कम है, लेकिन अगर ऐसा होता है, तो आप अक्सर कंपाइल ऑप्टिमाइजेशन को कम करके आसानी से डीबग क्रैश प्राप्त कर सकते हैं।

अधिकांश EXC_BAD_ACCESS त्रुटियां एक NULL पॉइंटर को रोकने की कोशिश के कारण होती हैं। यदि यह मामला है, तो लाल तीर में सूचीबद्ध पता आमतौर पर एक हेक्साडेसिमल संख्या होगी जो सामान्य मेमोरी पते से कम होती है, अक्सर 0x0 । डीबगर में ब्रेकपॉइंट सेट करें या कभी-कभी printf / NSLog स्टेटमेंट्स को यह पता लगाने के लिए जोड़ें कि क्यों सूचक NULL

एक EXC_BAD_ACCESS जो कम मज़बूती से होता है या कोई मतलब नहीं रखता है वह एक मेमोरी मैनेजमेंट समस्या का परिणाम हो सकता है। सामान्य समस्याएं जो इसका कारण बन सकती हैं:

  • ऐसी मेमोरी का उपयोग करना, जो निस्संकोच की गई है
  • सी सरणी या अन्य प्रकार के बफर के अंत में लिखने की कोशिश कर रहा है
  • एक पॉइंटर का उपयोग करना जिसे आरंभिक नहीं किया गया है

योजना संपादक के डायग्नोस्टिक्स अनुभाग में, डिस्को मेमोरी समस्याओं की सहायता के लिए Xcode में कुछ उपयोगी उपकरण शामिल हैं:

यहाँ छवि विवरण दर्ज करें

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



Modified text is an extract of the original Stack Overflow Documentation
के तहत लाइसेंस प्राप्त है CC BY-SA 3.0
से संबद्ध नहीं है Stack Overflow