अपने मैक के समस्या निवारण के लिए मैकोज़ क्रैश रिपोर्ट कैसे पढ़ें

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

क्रैश रिपोर्ट खोलना

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

1. स्पॉटलाइट में "कंसोल" टाइप करके या "एप्लिकेशन -> यूटिलिटीज -> कंसोल.एप" पर नेविगेट करके कंसोल एप्लिकेशन खोलें।

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 ) - असामान्य निकास, आमतौर पर एक अनकैप्ड सी ++ अपवाद के हाथ में और abort() पर कॉल करता है
• ट्रेस ट्रैप (EXC_BREAKPOINT / SIGTRAP ) - SIGABRT की तरह, लेकिन यह निकास संलग्न डिबगर को एक ब्रेकपॉइंट पर प्रक्रिया को बाधित करने और त्रुटि का पता लगाने का मौका देता है।
• अवैध निर्देश (EXC_BAD_INSTRUCTION / SIGILL ) - संसाधित ने एक निर्देश जारी किया जिसे समझा नहीं गया या संसाधित नहीं किया जा सका।
• छोड़ो (SIGQUIT ) - प्रक्रिया को पर्याप्त विशेषाधिकारों के साथ किसी अन्य प्रक्रिया द्वारा समाप्त कर दिया गया था। आमतौर पर, एक निगरानी प्रक्रिया दुर्व्यवहार की प्रक्रिया को समाप्त कर देती है।
• मारे गए (SIGKILL ) - सिस्टम के अनुरोध पर प्रक्रिया को समाप्त कर दिया गया था। अपवाद की व्याख्या करने के लिए एक समाप्ति कोड जोड़ा जाएगा।

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

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

उसके बाद हम दुर्घटना की ओर ले जाने वाली एक रिवर्स कालानुक्रमिक सूची देखते हैं। इन्हें थ्रेड द्वारा क्रमबद्ध किया जाता है, जो थ्रेड 0 से शुरू होता है।

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

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

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

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

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