Mac पर ऐप क्रैश आमतौर पर काफी दुर्लभ होते हैं। लेकिन जब वे होते हैं, तो आप उनके कारण का पता लगाना चाह सकते हैं। और यदि आप एक डेवलपर हैं, तो आपको यह समझने की आवश्यकता है कि आपका ऐप क्यों क्रैश हो रहा है। यहां macOS क्रैश रिपोर्ट पढ़ने और गूढ़ भाषा को छांटने का तरीका बताया गया है।
क्रैश रिपोर्ट खोलना
जब आपके Mac पर कोई ऐप क्रैश होता है, तो यह स्वचालित रूप से एक क्रैश रिपोर्ट जनरेट करता है। आप इसे क्रैश के बाद एक चेतावनी संवाद के साथ दिखाई देते हुए देखेंगे जिसमें कहा गया है "[ऐप] अप्रत्याशित रूप से बंद हो गया।" उस क्रैश रिपोर्ट को उस विंडो में "रिपोर्ट..." बटन पर क्लिक करके तुरंत पढ़ा जा सकता है। क्रैश रिपोर्ट कंसोल ऐप में भी पाई जा सकती है।
1. Spotlight में "Console" टाइप करके या "एप्लिकेशन -> यूटिलिटीज -> Console.app" पर नेविगेट करके कंसोल एप्लिकेशन खोलें।
2. बाएं मेनू में "उपयोगकर्ता रिपोर्ट" पर क्लिक करें, फिर उस क्रैश रिपोर्ट पर क्लिक करें जिसे आप देखना चाहते हैं। ये सभी फाइलें ".crash" में समाप्त होंगी और शीर्षक में तारीख और क्रैश हुए एप्लिकेशन शामिल होंगे। क्रैश रिपोर्ट का विवरण दाएं पेन में उपलब्ध है।
macOS क्रैश रिपोर्ट पढ़ना
आइए क्रैश रिपोर्ट को ऊपर से नीचे तक नेविगेट करें।
क्या क्रैश हुआ?
क्रैश रिपोर्ट का पहला भाग आपको बताता है कि कौन सी "प्रक्रिया" या एप्लिकेशन क्रैश हुई। औसत समस्या निवारक के लिए सबसे महत्वपूर्ण भाग प्रक्रिया का नाम है।
Process: aText [11473] Path: /Applications/aText.app/Contents/MacOS/aText Identifier: com.trankynam.aText Version: 2.19 (62) Code Type: X86-64 (Native) Parent Process: ??? [1] Responsible: aText [11473] User ID: 501
यह कब क्रैश हुआ?
दूसरा भाग हमें बताता है कि क्रैश कब हुआ। यह आपके सिस्टम के बारे में थोड़ी जानकारी भी प्रदान करता है।
Date/Time: 2018-03-15 00:58:10.552 -0400 OS Version: Mac OS X 10.12.6 (16G1036) Report Version: 12 Anonymous UUID: 6C985CFD-6975-3F30-50EB-0713315F5090 Time Awake Since Boot: 630000 seconds System Integrity Protection: enabled
क्रैश का कारण क्या था?
अगला भाग सबसे अधिक जानकारीपूर्ण है। एप्लिकेशन द्वारा प्रदान किया गया "अपवाद प्रकार" हमें बताता है कि क्रैश का कारण क्या था। लॉग यह भी रिपोर्ट करता है कि कौन सा थ्रेड क्रैश हुआ: इस मामले में, थ्रेड 0।
Crashed Thread: 0 Dispatch queue: com.apple.main-thread Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x000040dedeadbec0 Exception Note: EXC_CORPSE_NOTIFY Termination Signal: Segmentation fault: 11 Termination Reason: Namespace SIGNAL, Code 0xb Terminating Process: exc handler [0]
Apple अपने तकनीकी दस्तावेज में कुछ सामान्य अपवाद प्रकारों को सूचीबद्ध करता है:
- खराब मेमोरी एक्सेस (
EXC_BAD_ACCESS/SIGSEGV/SIGBUS) - प्रोग्राम गलत या अमान्य पते के साथ मेमोरी तक पहुंचने का प्रयास करता है। मेमोरी समस्या की व्याख्या करने वाले कोड के साथ संलग्न। - असामान्य निकास (
EXC_CRASH/SIGABRT) - असामान्य निकास, आमतौर पर अनकैच C++ अपवाद औरabort()कॉल के हाथों। - ट्रेस ट्रैप (
EXC_BREAKPOINT/SIGTRAP) - SIGABRT की तरह, लेकिन यह निकास संलग्न डिबगर को ब्रेकपॉइंट पर प्रक्रिया को बाधित करने और त्रुटि का पता लगाने का मौका देता है। - अवैध निर्देश (
EXC_BAD_INSTRUCTION/SIGILL) - प्रोसेस ने एक निर्देश जारी किया जो समझा नहीं गया या संसाधित नहीं किया जा सका। - छोड़ें (
SIGQUIT) - प्रक्रिया को पर्याप्त विशेषाधिकारों वाली किसी अन्य प्रक्रिया द्वारा समाप्त किया गया था। आमतौर पर, एक वॉचडॉग प्रक्रिया एक दुर्व्यवहार करने वाली प्रक्रिया को समाप्त करती है। - मारा गया (
SIGKILL) - प्रक्रिया को सिस्टम के अनुरोध पर समाप्त किया गया था। अपवाद की व्याख्या करने के लिए एक समाप्ति कोड संलग्न किया जाएगा।
जैसा कि हम अपनी क्रैश रिपोर्ट से देख सकते हैं, एप्लिकेशन ने अनमैप्ड मेमोरी तक पहुंचने का प्रयास किया। यह एप्लिकेशन में एक प्रोग्रामिंग त्रुटि या एक असामान्य उपयोगकर्ता स्थिति के कारण है जो एप्लिकेशन को मेमोरी को गलत तरीके से मैप करने का कारण बनती है।
क्रैश का कारण क्या बना?
उसके बाद हम देखते हैं कि क्रैश तक क्या हुआ, इसकी रिवर्स कालानुक्रमिक सूची। ये थ्रेड द्वारा क्रमबद्ध हैं, थ्रेड 0 से शुरू होकर।
इस रिपोर्ट में चार कॉलम हैं। पहला रिवर्स कालानुक्रमिक क्रम में घटना की संख्या की रिपोर्ट करता है, 0 से शुरू होकर। दूसरा प्रक्रिया का पहचानकर्ता है। तीसरा मेमोरी में प्रक्रिया का पता है। चौथा प्रोग्राम के कार्य का नाम है।
यह "बैकट्रेस" कुछ हद तक चकरा देने वाला हो सकता है। यह "सिम्बोलिकेटेड" है, अर्थात कुछ मेमोरी पतों को फ़ंक्शन नाम या एप्लिकेशन कार्यों से बदल दिया गया है। कभी-कभी यह पूरी तरह से नहीं किया जा सकता, जिससे रिपोर्ट में अपठनीय मेमोरी पते बिखरे रह जाते हैं।
हम इसे ऊपर की क्रैश रिपोर्ट में देखते हैं: com.trankynam.aText सिम्बोलिकेटेड नहीं है। पूर्ण सिम्बोलिकेशन के साथ भी, बैकट्रेस पढ़ना कठिन हो सकता है। कभी-कभी डेवलपर्स एप्लिकेशन कार्यों और घटनाओं के बारे में उपयोगी नोट्स शामिल करते हैं। अन्य बार, वे गूढ़ शीर्षक या संख्यात्मक कोड होते हैं। यदि आप सिम्बोलिकेशन का अर्थ समझ सकते हैं, तो आप समझ सकते हैं कि क्या हो रहा है। लेकिन यह भी उतना ही संभव है कि आपको बैकट्रेस का अर्थ समझने के लिए स्वयं एप्लिकेशन को कोड करना पड़े।
निष्कर्ष: क्या यह उपयोगी है?
यदि आप एक डेवलपर हैं, तो क्रैश रिपोर्ट पढ़ना आवश्यक है। यह आपको यह समझने में मदद करता है कि आपके एप्लिकेशन का कौन सा भाग क्रैश हो रहा है और क्यों। यदि आप एक उपयोगकर्ता हैं, तो वे उतने उपयोगी नहीं हैं। लेकिन यदि आपके पास लगातार क्रैश है, तो क्रैश रिपोर्ट समस्या का निवारण करने या डेवलपर के साथ समस्या को ठीक करने के लिए काम करने में आपकी मदद कर सकती हैं। आपको Google के लिए एक उपयोगी त्रुटि कोड मिल सकता है या तकनीकी सहायता को सही जानकारी प्रदान करने में सक्षम हो सकते हैं। यदि आप गहन विवरण चाहते हैं, तो आप Apple के क्रैश पर तकनीकी नोट में इसके बारे में सब पढ़ सकते हैं।
