Обычно сбой приложений на Mac случается очень редко. Но когда это произойдет, вы можете захотеть отслеживать эти проблемы. А если вы разработчик, вам нужно понимать, почему ваше приложение дает сбой. Вот как читать и сортировать отчеты о сбоях macOS по языку кодировки.
Открытые отчеты о сбоях
Когда приложение выходит из строя на вашем Mac, оно автоматически генерирует отчет о сбое. Вы увидите, что это появляется после сбоя в диалоговом окне с предупреждением: «[Приложение] неожиданно остановилось». Этот отчет о сбое доступен для немедленного чтения в этом окне, нажав кнопку «Отчет…». Отчет о сбое также можно найти в приложении консоли.
1. Откройте приложение консоли, набрав «Консоль» в Spotlight или перейдите в «Приложение -> Утилиты -> 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 ()
Trace Trap (EXC_BREAKPOINT / SIGTRAP) - то же самое, что и SIGABRT, но это завершение дает присоединенному отладчику возможность прервать процесс в точке останова и отследить ошибку.
Недопустимые инструкции (EXC_BAD_INSTRUCTION / SIGILL) - обработка выдала обработку, которая не была понята или не могла быть обработана.
Выйти (SIGQUIT) - процесс был прерван другим процессом с достаточными привилегиями. Обычно процесс мониторинга завершает процесс злоупотребления служебным положением.
Завершить (SIGKILL) - процесс был завершен по запросу системы. Для объяснения исключения будет добавлен код выхода.
Как видно из отчета о сбое, приложение пыталось получить доступ к не карантинной памяти. Это происходит из-за ошибки программирования в приложении или необычного состояния пользователя, из-за которого приложение неправильно отображает память.
Что приводит к неисправностям?
Затем мы видим обратный хронологический список того, что вызывает сбой. Они сортируются по потокам, начиная с потока 0.
В этом отчете четыре столбца. Первый сообщает номер события в обратном хронологическом порядке, начиная с 0. Второй - это идентификатор процесса. Третье - это адрес процесса в памяти. Четвертый - это название задачи программы.
Эта «отмена» может немного сбить с толку. Они являются «символическими», что означает, что некоторые адреса памяти были заменены именами функций или задач приложения. Иногда это невозможно сделать полностью, в результате чего нечитаемые адреса памяти засоряются отчетом.
Мы видим это в отчете о сбое выше: com.trankynam.aText не является токеном. Даже при полном кодировании фон может быть трудночитаемым. Разработчики программного обеспечения иногда включают полезные примечания о задачах и событиях приложения. В других случаях это зашифрованные адреса или числовой код. Если вы сможете понять символизм, вы сможете понять, что происходит. Но в максимально возможной степени вам нужно будет написать приложение самостоятельно, чтобы понять обратную трассировку.
Заключение: полезно ли это?
Если вы разработчик программного обеспечения, обязательно прочтите отчеты о сбоях. Это поможет вам понять, какая часть вашего приложения вызывает проблемы и почему. Если вы пользователь, они бесполезны. Но если у вас постоянный сбой, отчеты о сбоях могут помочь вам устранить проблему или поработать с разработчиком, чтобы исправить проблему. Вы можете получить код ошибки, исправленный через Google, или отправить его в службу технической поддержки с правильной информацией. Если вам нужны серьезные подробности, вы можете прочитать все об этом на Техническое примечание Apple о сбоях.
