كيفية قراءة تقارير الأعطال على Mac OS لاستكشاف الأخطاء وإصلاحها

عادةً ما يكون تعطل التطبيقات على جهاز Mac نادرًا جدًا. ولكن عندما يحدث ذلك ، قد ترغب في تتبع هذه المشاكل. وإذا كنت مطورًا ، فأنت بحاجة إلى فهم سبب تعطل تطبيقك. إليك كيفية قراءة تقارير الأعطال في macOS وفرزها من خلال اللغة المشفرة.

فتح تقارير الأعطال

عندما يتعطل تطبيق ما على جهاز Mac ، فإنه ينشئ تقرير عطل تلقائيًا. سترى هذا يظهر بعد العطل من خلال مربع حوار تحذير يقول “[تطبيق] قد توقف بشكل غير متوقع.” يتوفر تقرير العطل هذا للقراءته على الفور في هذه النافذة من خلال النقر على الزر “إبلاغ …”. يمكن أيضًا العثور على تقرير الأعطال في تطبيق Console.

1. افتح تطبيق Console بكتابة “Console” في Spotlight أو انتقل إلى “Application -> Utilities -> Console.app.”

2. انقر على “تقارير المستخدم” في القائمة اليسرى، ثم انقر فوق تقرير العطل الذي تريد عرضه. تنتهي جميع هذه الملفات بـ “.crash” وتتضمن التاريخ والتطبيق المعطوب في العنوان. تتوفر تفاصيل تقرير الأعطال في الجزء الموجود على اليمين.

قراءة تقارير أعطال Mac OS

دعنا نتصفح تقرير الأعطال من الأعلى لأسفل.

ما الذي تعطل؟

يوضح لك الجزء الأول من تقرير الأعطال هل الذي”تعطل” عملية أو تطبيق. الجزء الأكثر أهمية بالنسبة إلى أداة تحرّي الخلل وإصلاحه هو اسم العملية.

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) – أصدرت المعالجة معالجة لم يتم فهمها أو تعذرت معالجتها.

Quit (SIGQUIT) – تم إنهاء العملية من خلال عملية أخرى بامتيازات كافية. عادة ، تنهي عملية المراقبة عملية سوء التصرف.

إنهاء (SIGKILL) – تم إنهاء العملية بناء على طلب النظام. سيتم إلحاق رمز الإنهاء لشرح الاستثناء.

كما نرى من تقرير الأعطال ، حاول التطبيق الوصول إلى الذاكرة غير المعزولة. هذا بسبب خطأ في برمجة في التطبيق أو حالة مستخدم غير عادي تسبب التطبيق لتعيين الذاكرة بشكل غير صحيح.

ما الذي يؤدي إلى العطل؟

بعد ذلك ، نرى قائمة ترتيب زمني عكسي لما يؤدي إلى الانهيار. يتم فرز هذه حسب مؤشر الترابط ، بدءاً من مؤشر ترابط 0.

هناك أربعة أعمدة لهذا التقرير. تشير التقارير الأولى إلى رقم الحدث بترتيب زمني عكسي ، بدءًا من 0. والثاني هو معرّف العملية. والثالث هو عنوان العملية في الذاكرة. الرابع هو اسم مهمة البرنامج.

هذا “التراجع” يمكن أن يكون محيرًا إلى حدٍ ما. إنها “رمزية” ، بمعنى أنه قد تم استبدال بعض عناوين الذاكرة بأسماء الدوال أو مهام التطبيق. في بعض الأحيان لا يمكن القيام بذلك تمامًا ، تاركًا عناوين الذاكرة غير القابلة للقراءة منتشرة في التقرير.

نرى هذا في تقرير الأعطال أعلاه: com.trankynam.aText غير رمزي. حتى مع الترميز الكامل ، قد يكون من الصعب قراءة الخلفية. يشمل مطورو البرامج أحيانًا ملاحظات مفيدة حول مهام وأحداث التطبيق. في أوقات أخرى ، فهي عبارة عن عناوين مشفرة أو رمز رقمي. إذا كنت تستطيع فهم الرمزية ، فقد تتمكن من فهم ما يحدث. ولكن بقدر الإمكان ، ستحتاج إلى ترميز التطبيق بنفسك لفهم backtrace.

الخلاصة: هل هذا مفيد؟

إذا كنت مطور برامج ، فمن الضروري قراءة تقارير الأعطال. يساعدك ذلك على فهم أي جزء من تطبيقك يسبب مشاكل ولماذا. إذا كنت مستخدمًا ، فهي ليست مفيدة. ولكن إذا كان لديك تعطل مستمر ، يمكن أن تساعدك تقارير الأعطال على تحرّي المشكلة وإصلاحها أو العمل مع مطوّر البرامج لإصلاح المشكلة. قد تحصل على حل رمز الخطأ بشكل مفيد من خلال Google أو يمكنك تقديمه الى الدعم الفني بالمعلومات الصحيحة. إذا كنت تريد تفاصيل جذرية، فيمكنك قراءة كل شيء عنها في ملاحظة Apple الفنية بشأن الأعطال.

DzTech

أنا مهندس دولة مع خبرة واسعة في مجالات البرمجة وإنشاء مواقع الويب وتحسين محركات البحث والكتابة التقنية. أنا شغوف بالتكنولوجيا وأكرس نفسي لتقديم معلومات عالية الجودة للجمهور. يُمكنني أن أصبح موردًا أكثر قيمة للمُستخدمين الذين يبحثون عن معلومات دقيقة وموثوقة حول مُراجعات المُنتجات والتطبيقات المُتخصصة في مُختلف المجالات. إنَّ التزامي الثابت بالجودة والدقة يضمن أنَّ المعلومات المُقدمة جديرة بالثقة ومفيدة للجمهور. السعي المُستمر للمعرفة يدفعني إلى مواكبة أحدث التطورات التكنولوجية، مما يضمن نقل الأفكار المُشتركة بطريقة واضحة وسهلة المنال.
زر الذهاب إلى الأعلى