मैक पर ऐप क्रैश आमतौर पर बहुत दुर्लभ होते हैं। लेकिन जब वे होते हैं, तो आप उनके कारण का पता लगाना चाहेंगे। और यदि आप एक डेवलपर हैं, तो आपको समझना होगा कि आपका ऐप क्यों क्रैश हो रहा है। यहां मैकोज़ क्रैश रिपोर्ट को पढ़ने और क्रिप्टिक भाषा के माध्यम से सॉर्ट करने का तरीका बताया गया है।

खुली क्रैश रिपोर्ट्स

जब आपके मैक पर ऐप क्रैश हो जाता है, तो यह स्वचालित रूप से क्रैश रिपोर्ट उत्पन्न करता है। आपको यह चेतावनी संवाद के साथ दुर्घटना के बाद दिखाई देगा " [ऐप] अप्रत्याशित रूप से बाहर निकल गया है। "उस क्रैश रिपोर्ट को" रिपोर्ट ... "बटन पर क्लिक करके तुरंत उस विंडो में पढ़ने के लिए उपलब्ध है। कंसोल ऐप में क्रैश रिपोर्ट भी मिल सकती है।

1. स्पॉटलाइट में "कंसोल" टाइप करके या "एप्लिकेशन -> उपयोगिताओं -> Console.app" पर नेविगेट करके कंसोल एप्लिकेशन खोलें।

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

मैकोज़ क्रैश रिपोर्ट पढ़ना

आइए क्रैश रिपोर्ट को ऊपर से नीचे तक नेविगेट करें।

क्या दुर्घटनाग्रस्त हो गया?

क्रैश रिपोर्ट का पहला भाग आपको बताता है कि "प्रक्रिया" या एप्लिकेशन क्रैश हो गया है। औसत समस्या निवारक के लिए सबसे महत्वपूर्ण हिस्सा प्रक्रिया का नाम है।

 प्रक्रिया: एटेक्स्ट [11473] पथ: / अनुप्रयोग /aText.app/Contents/MacOS/aText पहचानकर्ता: com.trankynam.aText संस्करण: 2.1 9 (62) कोड का प्रकार: X86-64 (मूल) अभिभावक प्रक्रिया: ??? [1] जिम्मेदार: एटेक्स्ट [11473] उपयोगकर्ता आईडी: 501

यह कब दुर्घटनाग्रस्त हो गया?

दूसरा भाग हमें बताता है कि दुर्घटना कब हुई। यह आपके सिस्टम के बारे में थोड़ी सी जानकारी भी प्रदान करता है।

 तिथि / समय: 2018-03-15 00: 58: 10.552 -0400 ओएस संस्करण: मैक ओएस एक्स 10.12.6 (16 जी 1036) रिपोर्ट संस्करण: 12 बेनामी यूयूआईडी: 6 सी 9 85 सीएफडी -6 9 75-3 एफ 30-50 ईबी -0713315 एफ 50 9 0 बूट के बाद से जागृत: 630000 सेकंड सिस्टम इंटीग्रटी प्रोटेक्शन: सक्षम

क्या दुर्घटना हुई?

अगला भाग सबसे रोशनी है। एप्लिकेशन द्वारा प्रदान किया गया "अपवाद प्रकार" हमें बताता है कि क्रैश का कारण क्या है। लॉग यह भी रिपोर्ट करता है कि कौन सा धागा दुर्घटनाग्रस्त हो गया: इस मामले में, धागा 0।

 क्रैश थ्रेड: 0 डिस्पैच कतार: com.apple.main-thread अपवाद प्रकार: EXC_BAD_ACCESS (SIGSEGV) अपवाद कोड: 0x000040dedeadbec0 पर KERN_INVALID_ADDRESS अपवाद नोट: EXC_CORPSE_NOTIFY समाप्ति सिग्नल: सेगमेंटेशन गलती: 11 समाप्ति कारण: नामस्थान सिग्नल, कोड 0xb टर्मिनिंग प्रक्रिया: exc हैंडलर [0]

ऐप्पल अपने तकनीकी दस्तावेज में कुछ सामान्य अपवाद प्रकार सूचीबद्ध करता है:

  • खराब मेमोरी एक्सेस ( EXC_BAD_ACCESS / SIGSEGV / SIGBUS ) - प्रोग्राम गलत तरीके से या अमान्य पते के साथ स्मृति तक पहुंचने का प्रयास करता है। स्मृति समस्या को समझाते हुए एक कोड के साथ जोड़ा गया।
  • असामान्य निकास ( EXC_CRASH / EXC_CRASH ) - असामान्य निकास, आमतौर पर एक बेकार सी ++ अपवाद के हाथ में और abort() करने के लिए कॉल abort()
  • ट्रेस ट्रैप ( EXC_BREAKPOINT / SIGTRAP ) - SIGTRAP तरह, लेकिन यह निकास संलग्न डीबगर को ब्रेकपॉइंट पर प्रक्रिया को बाधित करने और त्रुटि का पता लगाने का मौका देता है।
  • अवैध निर्देश ( EXC_BAD_INSTRUCTION / SIGILL ) - संसाधित एक निर्देश जारी किया गया जिसे समझा नहीं गया था या संसाधित नहीं किया जा सका।
  • बाहर निकलें ( SIGQUIT ) - प्रक्रिया को पर्याप्त विशेषाधिकारों के साथ दूसरी प्रक्रिया द्वारा समाप्त कर दिया गया था। आम तौर पर, एक वॉचडॉग प्रक्रिया एक गलत व्यवहार प्रक्रिया को समाप्त कर देती है।
  • मारे गए ( SIGKILL ) - प्रक्रिया को सिस्टम के अनुरोध पर समाप्त कर दिया गया था। अपवाद की व्याख्या करने के लिए एक समाप्ति कोड जोड़ा जाएगा।

जैसा कि हम अपनी क्रैश रिपोर्ट से देख सकते हैं, एप्लिकेशन ने अप्रयुक्त स्मृति तक पहुंचने का प्रयास किया। यह एप्लिकेशन में प्रोग्रामिंग त्रुटि या असामान्य उपयोगकर्ता स्थिति के कारण है जो एप्लिकेशन को स्मृति को गलत तरीके से मैप करने का कारण बनता है।

दुर्घटना का क्या कारण है?

इसके बाद हम क्रैश तक पहुंचने की एक रिवर्स क्रोनोलॉजिकल सूची देखते हैं। ये धागे से क्रमबद्ध होते हैं, धागे 0 से शुरू होते हैं।

इस रिपोर्ट में चार कॉलम हैं। पहली बार इवेंट की संख्या रिवर्स क्रोनोलॉजिकल ऑर्डर में 0 से शुरू होती है। दूसरा प्रक्रिया की पहचानकर्ता है। तीसरा स्मृति में प्रक्रिया का पता है। चौथा कार्यक्रम के कार्य का नाम है।

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

हम इसे उपरोक्त क्रैश रिपोर्ट में देखते हैं: com.trankynam.aText प्रतीकात्मक नहीं है। पूर्ण प्रतीकात्मकता के साथ भी, बैकट्रैक को पढ़ना मुश्किल हो सकता है। कभी-कभी डेवलपर्स में एप्लिकेशन कार्यों और घटनाओं के बारे में उपयोगी नोट्स शामिल होते हैं। अन्य बार, वे गुप्त शीर्षक या संख्यात्मक कोड हैं। यदि आप प्रतीकात्मकता को समझ सकते हैं, तो आप यह समझने में सक्षम हो सकते हैं कि क्या हो रहा है। लेकिन यह उतना ही संभव है कि आपको बैकट्रैस को समझने के लिए स्वयं को कोड को कोड करना होगा।

निष्कर्ष: क्या यह उपयोगी है?

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