Обычно сбой приложений на Mac случается очень редко. Но когда это произойдет, вы можете захотеть отслеживать эти проблемы. А если вы разработчик, вам нужно понимать, почему ваше приложение дает сбой. Вот как читать и сортировать отчеты о сбоях macOS по языку кодировки.
Быстрые ссылки
Открытые отчеты о сбоях
Когда приложение выходит из строя на вашем Mac, оно автоматически генерирует отчет о сбое. Вы увидите, что это появляется после сбоя в диалоговом окне с предупреждением: «[Приложение] неожиданно остановилось». Этот отчет о сбое доступен для немедленного чтения в этом окне, нажав кнопку «Отчет…». Отчет о сбое также можно найти в приложении консоли.
1. Откройте приложение консоли, набрав «Консоль» в Spotlight или перейдите в «Приложение -> Утилиты -> Console.app».
2. Щелкните «Отчеты пользователей» в левом меню, затем щелкните отчет о сбоях, который вы хотите просмотреть. Все эти файлы заканчиваются на «.crash» и включают в заголовок дату и сломанное приложение. Подробная информация об отчете о сбое доступна на панели справа.
Прочтите отчеты о сбоях Mac OS
Давайте рассмотрим отчет о сбое сверху вниз.
Что именно вылетает?
Первая часть отчета о сбоях покажет вам, «вылетает» ли процесс или приложение. Самая важная часть для средства устранения неполадок - это название процесса.
Процесс: aText [11473] Путь: /Applications/aText.app/Contents/MacOS/aText Идентификатор: com.trankynam.aText Версия: 2.19 (62) Тип кода: X86-64 (собственный) Родительский процесс: ??? [1] Ответственный: aText [11473] Идентификатор пользователя: 501
Когда были праздники?
Вторая часть сообщает нам, когда произошла неисправность. Он также предоставляет небольшую информацию о вашей системе.
Дата/время: 2018-03-15 00:58:10.552 -0400 Версия ОС: Mac OS X 10.12.6 (16G1036) Версия отчета: 12 Анонимный UUID: 6C985CFD-6975-3F30-50EB-0713315F5090 Время активности с момента загрузки: 630000 секунд Защита целостности системы: включена
Что вызвало неисправность?
Следующая часть наиболее показательна. «Тип исключения», предлагаемый приложением, сообщает нам, что вызвало неисправность. Журнал также сообщает, какой поток потерпел крах: в данном случае поток 0.
Сбой потока: 0 Очередь отправки: com.apple.main-thread Тип исключения: EXC_BAD_ACCESS (SIGSEGV) Коды исключений: KERN_INVALID_ADDRESS в 0x000040dedeadbec0 Примечание об исключении: EXC_CORPSE_NOTIFY Сигнал завершения: Ошибка сегментации: 11 Причина завершения: СИГНАЛ пространства имен, код 0xb Процесс завершения: 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 о сбоях.
