کرش کردن اپلیکیشن‌ها در سیستم عامل macOS به ندرت اتفاق می‌افتد. اما اگر چنین اتفاقی افتاد، آیا دوست ندارید بدانید علت آن چه بوده است؟ گاهی اوقات تعداد دفعات کرش کردن برنامه‌ها آن‌قدر زیاد می‌شود که دیگر توان تحمل کردن آن را نخواهید داشت.
اگر توسعه‌دهنده‌ی نرم‌افزار هستید، باید بدانید که چرا اپلیکیشن شما کرش می‌کند. یکی از مهم‌ترین وظایف همه‌ی برنامه‌نویس‌ها مشکل‌یابی ایرادات فعلی برنامه است.
در ادامه به شما می‌گوییم که چطور گزارشات کرش مکینتاش را بخوانید و از میان آن همه نوشته‌ی رمزآلود مشکلات سیستم را پیدا کنید. پس با سیاره‌ی آی‌تی همراه باشید.
باز کردن بخش گزارشات کرش در مک‌او‌اس
وقتی یک اپلیکیشن در مک کرش می‌کند، به طور خودکار از این کرش کردن یک گزارش تولید می‌شود. پنجره‌ای که بعد از هر کرش با عنوان App has quit unexpectedly. به نمایش در می‌آید به همین دلیل ظاهر می‌شود و با کلیک کردن بر روی دکمه‌ی Report بلافاصله می‌توانید گزارش آن را ببینید. علاوه بر این از طریق اپلیکیشن Console هم می‌توانید به این گزارشات دسترسی داشته باشید؛ روش استفاده از این برنامه به شرح زیر است:
در Spotlight عبارت Console را جستجو کنید یا از مسیر Application -> Utilities -> Console.app این برنامه را باز نمایید.
از منوی سمت چپ روی گزینه‌ی User Reports کلیک کنید، سپس گزارش موردنظر خود را باز نمایید. نام فایل هر گزارش حاوی تاریخ و اسم اپلیکیشن مربوطه است و پسوند آن .crash می‌باشد. جزئیات گزارش کرش در پنل سمت راست موجود است.
خواندن گزارشات کرش مک برای عیب‌یابی
حالا بیایید با هم همه‌ی بخش‌های یک گزارش کرش را از بالا تا پایین بررسی کنیم.
چه چیزی کرش کرده؟
اولین قسمت گزارش به شما می‌گوید که کدام پروسه یا اپلیکیشن کرش کرده است. مهم‌ترین بخشی که هر کاربر عادی برای مشکل‌یابی با آن روبرو می‌باشد نام پروسه است.
Process: aText [11473]Path: /Applications/aText.app/Contents/MacOS/aTextIdentifier: com.trankynam.aTextVersion: 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 -0400OS Version: Mac OS X 10.12.6 (16G1036)Report Version: 12Anonymous UUID: 6C985CFD-6975-3F30-50EB-0713315F5090 Time Awake Since Boot: 630000 seconds System Integrity Protection: enabled
علت کرش چه بوده؟
قسمت بعدی آشکارکننده‌ترین بخش گزارش است. exception type مشخص می‌کند که علت کرش چه چیزی بوده است. علاوه بر این می‌توانید ببینید که کدام رشته‌ی پردازش کرش کرده؛ در مثال زیر این رشته شماره‌ی صفر است.
Crashed Thread: 0 Dispatch queue: com.apple.main-thread Exception Type: EXC_BAD_ACCESS (SIGSEGV)Exception Codes: KERN_INVALID_ADDRESS at 0x000040dedeadbec0Exception Note: EXC_CORPSE_NOTIFY Termination Signal: Segmentation fault: 11Termination Reason: Namespace SIGNAL, Code 0xbTerminating Process: exc handler [0]
اپل در مستندات فنی خود برخی از exception type-های رایج را معرفی کرده است:
- دسترسی بد به حافظه (EXC_BAD_ACCESS/SIGSEGV/SIGBUS) – برنامه سعی کرده به اشتباه یا با یک آدرس غیرمعتبر به حافظه دسترسی یابد. این حالت همراه با کدی ارائه می‌شود که مشکل حافظه را توضیح می‌دهد.
- خروج غیرعادی (EXC_CRASH/SIGABRT) – این حالت معمولاً به خاطر نارسایی C++ و فراخوانی تابع abort() به وجود می‌آید.
- تله‌ی ردیابی (EXC_BREAKPOINT/SIGTRAP) – این حالت هم مثل SIGABRT است اما این خروج به دیباگِر اجازه می‌دهد تا پروسه را در یک نقطه‌ی توقف قطع کند و خطا را بیابد.
- دستور غیرقانونی (EXC_BAD_INSTRUCTION/SIGILL) – پروسه دستوری صادر کرده که قابل فهم یا قابل پردازش نبوده است.
- خروج (SIGQUIT) – پروسه با دسترسی‌های کافی توسط یک پروسه‌ی دیگر بسته شده است. به طور معمول، یک پروسه‌ی نگهبان پروسه‌ای که رفتارهای نامتعارف داشته باشد را می‌بندد.
- بسته شده (SIGKILL) – پروسه به درخواست سیستم بسته شده است. کد بسته شدن هم برای توضیح مشکل همراه این پیام ارائه می‌شود.
همان طور که در مثال می‌بینیم، اپلیکیشن ما سعی داشته تا به یک بخش نامشخص از حافظه دسترسی یابد. این مشکل به خاطر برنامه‌نویسی غلط یا وضعیت غیرمتداول حساب کاربری شخص به وجود آمده و باعث شده تا دسترسی به حافظه ممکن نباشد.
چه چیزی منجر به کرش شده؟
در تصویر بالا لیستی را می‌بینید که به ترتیبِ آخرین وقایع، هر آنچه که منجر به کرش شده را نشان می‌دهد. این لیست بر اساس رشته‌ها و با رشته‌ی شماره‌ی صفر مرتب شده است.
در این گزارش چهار ستون وجود دارد. اولین ستون مربوط به شماره‌ی رویداد به ترتیب زمانی معکوس می‌باشد که با صفر شروع شده است. ستون دوم آیدی مشخص‌کننده‌ی پروسه است. ستون سوم آدرس پروسه در حافظه می‌باشد و چهارمی هم نام تسک (Task) آن برنامه را نشان می‌دهد.
درک توضیحات این گزارش کمی مشکل است چون اطلاعات آن به صورت فنی نوشته شده و برای ما که معمولاً همه چیز را به طور سمبلیک می‌بینیم قابل فهم نیست. سمبلیک یعنی آدرس‌های حافظه با نام توابع یا اپلیکیشن‌ها جایگزین شود.
در تصویر بالا com.trankynam.aText به صورت سمبلیک نوشته نشده است. حتی اگر به شکل سمبلیک هم نوشته می‌شد، باز هم درک آن سخت بود. بعضی وقت‌ها توسعه‌دهندگان توضیحات مفیدی درباره‌ی تسک‌ها و رویدادهای برنامه ارائه می‌دهند. ولی این عناوین اغلب به صورت رمزی و عددی است. اگر از این‌ها سر در می‌آورید، شاید بفهمید چه اتفاقی رخ داده. ولی معمولاً به جز سازنده‌ی خود برنامه کسی از این نوشته‌ها چیزی نمی‌فهمد.
جمع‌بندی: این کار فایده‌ای هم دارد؟
اگر توسعه‌دهنده هستید، خواندن بخش گزارشات کرش برای شما ضروری است. با این کار می‌توانید بفهمید که کدام قسمت از اپلیکیشن شما کرش می‌کند و علت آن چیست. اما اگر کاربر عادی هستید، این گزارشات زیاد به درد شما نمی‌خورد. با این حال اگر یکی از اپلیکیشن‌های شما زیاد کرش می‌کند می‌تواند سری به این بخش بزنید تا ببینید مشکل چیست یا گزارش آن را برای توسعه‌دهنده‌ی نرم‌افزار بفرستید تا ایراد را برطرف کند. در این مواقع معمولاً با یک جستجوی ساده در گوگل هم می‌توانید به نتایج خوبی برسید.
maketecheasierسیاره‌ی آی‌تی