Сбои приложений на Mac, как правило, случаются довольно редко. Но когда они случаются, возможно, вам захочется выяснить их причину. И если вы разработчик, вам нужно понять, почему ваше приложение дает сбой. Вот как читать отчеты о сбоях macOS и разбираться в загадочном языке.
Читайте также: 8 способов исправить не отвечающие приложения и зависания системы на Mac
Открытие отчетов о сбоях
При сбое приложения на вашем Mac оно автоматически создает отчет о сбое. Вы увидите это после сбоя с диалоговым окном с предупреждением о том, что «[Прило ContentsОткрытие отчетов о сбоях
у.». Этот отчет о сбое можно сразу же прочитать в этом окне, нажав кнопку «Сообщить…». Отчет о сбое также можно найти в приложении Console.
1. Откройте приложение консоли, введя «Консоль» в Spotlight или перейдя в «Приложение ->Утилиты ->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.Чтение отчетов о сбоях macOS
nymous UUID: 6C985CFD-6975-3F30-50EB-0713315F5090 Time Awake Since Boot: 630000 secondЧто сломалось?
otection: 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Когда произошел сбой?
ple перечисляет около распространенные типы исключений в своей технической документации:
- Неверный доступ к памяти (
EXC_BAD_ACCESS/SIGSEGV/SIGBUS) – программа пытается получить доступ к памяти неправильно или по неверному адресу.. Прилагается код, объясняющий проблему с памятью. - Аварийный выход (
EXC_CRASH/SIGABRT) – аварийный выход, обычно из-за неперехвачеЧто стало причиной сбоя?
ode>abort() - Trace Trap (
EXC_BREAKPOINT/SIGTRAP) — аналогично SIGABRT, но этот выход дает подключенному отладчику возможность прервать процесс в точке останова и отследить ошибку. - Недопустимая инструкция (
EXC_BAD_INSTRUCTION/SIGILL) — обрабатываемый выдал инструкцию, которая не была понята или не могла быть обработана. - Выйти (
SIGQUIT) – процесс был завершен другим процессом с достаточными привилегиями. Обычно сторожевой процесс завершает неправильно работающий процесс. - Убит (
SIGKILL) – процесс был прекращен по требованию системы. Для объяснения исключения будет добавлен код завершения.
Как видно из нашего отчета о сбое, приложение пыталось получить доступ к неотображенной памяти. Это происходит из-за программной ошибки в приложении или необычного состояния пользователя, из-за которого приложение неправильно отображает память.
Что привело к сбою?
После этого мы видим обратный хронологический список того, что привело к катастрофе. Они сортируются по потокам, начиная с потока 0.
В этом отчете четыре столбца. Первый сообщает номер события в обратном хронологическом порядке, начиная с 0. Второй — идентификатор процесса. Третий — адрес процесса в памяти. Четвертое — название задачи программы.
Этот «обратный след» может сбивать с толку. Он «символизирован», что означает, что некоторые адреса памяти были заменены именами функций или задачами приложений. Иногда это не удается сделать полностью, в результате чего в отчете разбросаны нечитаемые адреса памяти.
Мы видим это в отчете о сбое выше: com.trankynam.aTextне обозначено. Даже при наличии полной символики может быть трудно прочитать обратную трассировку. Иногда разработчики включают полезные заметки о задачах и событиях приложения. В других случаях это загадочные названия или числовой код. Если вы сможете разобраться в символике, вы, возможно, сможете понять, что происходит. Но также возможно, что вам придется написать код приложения самостоятельно, чтобы разобраться в обратной трассировке.
Вывод: полезно ли это?
Если вы разработчик, вам необходимо читать отчеты о сбоях. Это поможет вам понять, какая часть вашего приложения дает сбой и почему. Если вы пользователь, они не так полезны. Но если у вас постоянный сбой, отчеты о сбоях могут помочь вам устранить проблему или обратиться к разработчику для ее устранения. Вы можете получить полезный код ошибки в Google или предоставить техническую поддержку нужной информации. Если вам нужны кровавые подробности, вы можете прочитать все об этом в Техническое примечание Apple о сбоях .
