Как читать отчёты об авариях приложений на macOS

Программные сбои на Mac встречаются редко, но когда они происходят, полезно уметь прочитать отчёт об аварии. Разработчикам эти отчёты помогают понять причину падения; пользователям — собрать нужную информацию для техподдержки. Ниже — пошаговое руководство по чтению отчётов, советы по диагностике и чек-листы для разных ролей.

Открытие отчётов об авариях

Когда приложение аварийно завершает работу, macOS создаёт отчёт и показывает диалог с сообщением «[App] завершил работу неожиданно.» В этом диалоге можно нажать кнопку «Отправить»/«Сообщить…» или просмотреть сам отчёт через Консоль.

1. Откройте приложение «Консоль» (Console.app) — через Spotlight или из «Приложения -> Утилиты -> Консоль».

2. В левой колонке выберите «User Reports» (Пользовательские отчёты), затем кликните файл с расширением .crash. В названии файла обычно указана дата и имя упавшего приложения. Детали показываются в правой панели.

Важно: сохраните файл .crash, если планируете отправить его разработчику или прикрепить к обращению в поддержку.

Чтение отчёта об аварии: по разделам

Ниже — разбор типичной структуры отчёта. Мы идём сверху вниз: сначала общая информация о процессе, затем дата/состояние системы, описание исключения и стек вызовов.

Что упало?

Первый блок показывает процесс и путь к исполняемому файлу. Для устранения неполадок наиболее полезно имя процесса и идентификатор пакета.

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

Пояснение: “Process” — имя и PID процесса. “Identifier” — уникальный идентификатор приложения (bundle identifier). “Code Type” показывает архитектуру сборки.

Когда это произошло?

Второй блок содержит отметку времени и сведения о системе.

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

Это помогает понять контекст: версия macOS, активирован ли SIP, сколько времени прошло с момента загрузки системы.

Что вызвало сбой?

Самый информативный блок — тип исключения и строка, где указана нить (thread), которая упала.

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]

Ключевые типы исключений (общие объяснения):

• EXC_BAD_ACCESS / SIGSEGV / SIGBUS — ошибка доступа к памяти (некорректный указатель или обращение к освобождённой памяти).
• EXC_CRASH / SIGABRT — аварийное завершение, часто вследствие вызова abort() или непойманного исключения в C++/ObjC.
• EXC_BREAKPOINT / SIGTRAP — сигнал от точки останова или отладки.
• EXC_BAD_INSTRUCTION / SIGILL — процесс выполнил некорректную или несуществующую инструкцию.
• SIGQUIT — процесс завершён другим процессом (например, watchdog).
• SIGKILL — процесс принудительно завершён системой.

Важно: код исключения и адрес (в примере 0x000040dedeadbec0) указывают, какая именно память была недоступна. Для разработчика это подсказка, где искать.

Что привело к аварии? (обратный трассировочный список)

Далее идёт “backtrace” — список вызовов, предшествовавших падению, отсортированный по нитям. Обычно он разделён на четыре колонки: номер кадра, PID/идентификатор, адрес в памяти, имя функции/задачи.

Этот стек может быть частично или полностью символицирован: символы заменяют адреса на имена функций. Если символы отсутствуют, вы увидите только адреса. Полная символика требует наличия dSYM — отладочных символов из сборки приложения.

Пример: если вы видите своё имя функции в backtrace, у вас хороший шанс воспроизвести и исправить ошибку. Если видны только адреса и системные библиотеки — нужно получить dSYM или собрать приложение с включёнными символами.

Когда отчёт полезен, а когда — нет

Важно понимать ограничения:

• Полезно: когда проблема воспроизводится последовательно, или когда есть символы/dSYM — отчёт часто указывает точную функцию и строку.
• Менее полезно: когда backtrace полностью без символов, или падение происходит в системном коде без явного приложения-виновника.
• Неполезно: при аппаратных сбоях или повреждении памяти вне программы; тогда отчёт даёт лишь симптом, но не причину.

Практическая методика для разработчика (мини-методология)

1. Соберите все доступные отчёты для одной ошибки — ищите совпадающие Exception Type и стек вызовов.
2. Сопоставьте время падения с логами приложения и сервера (если есть).
3. Убедитесь, что у вас есть dSYM для релиза, соответствующий версии приложения.
4. Произведите symbolication: подгрузите dSYM в инструменты (Console, Xcode или atos) и интерпретируйте стек.
5. Воспроизведите ситуацию локально: те же входные данные, те же права доступа, те же версии библиотек.
6. Добавьте логирование/assert’ы и напишите тест, покрывающий проблемный путь.
7. Подготовьте исправление и запишите регрессионный тест.

Совет: если падение связано с памятью, проверьте работу с указателями, владение объектами, многопоточность и race conditions.

Чек-лист по ролям

Разработчик:

• Получить .crash и соответствующий dSYM.
• Проанализировать Exception Type и Crashed Thread.
• Симболизировать стек и найти вызывающие функции.
• Добавить тесты и логирование, исправить код.

Инженер поддержки:

• Спросить пользователя об обстоятельствах: что делал(а) перед падением.
• Попросить файл .crash и версию приложения.
• Сопоставить с уже известными баг-репортами.
• Передать отчёт разработчикам с описанием воспроизводимости и окружения.

Конечный пользователь:

• Повторить шаги, если проблема воспроизводится и прикрепить .crash к обращению.
• Установить обновления macOS и приложения — иногда это решает проблему.
• Временно переустановить приложение, если это несложно.

Альтернативные подходы и когда использовать их

• Если отчёт не символицирован — попросите у пользователя релизный dSYM (для внутренних тестов) или соберите дополнительный лог на уровне приложения.
• Для проблем многопоточности используйте инструменты для динамического анализа (Thread Sanitizer, Address Sanitizer при сборке). Они помогают обнаружить гонки и нарушения доступа к памяти.
• Если проблема повторяется только у одного пользователя — проверьте окружение: плагины, расширения, нестандартные настройки доступа к файлам.

Ментальные модели при разборе падений

• Исключение памяти → искать владение/жизненный цикл объекта.
• SIGABRT/uncaught exception → искать непойманные исключения, assert’ы, вызовы abort().
• Повторяющиеся падения в одной функции → баг в алгоритме, возможно, при особых входных данных.

Факт-бокс: ключевые поля отчёта

• Process — имя процесса и PID.
• Path — путь к приложению.
• Identifier — bundle identifier.
• Date/Time — отметка времени.
• OS Version — версия macOS.
• Exception Type / Codes — тип и код исключения.
• Crashed Thread — какая нить упала.
• Backtrace — стек вызовов по нитям.

Как символизировать стек (кратко)

1. Откройте .crash в Xcode или Консоли — Xcode автоматически попытается символизировать, если у него есть dSYM.
2. Если автоматической символики нет, используйте команду atos или tools из Xcode, указав адрес и dSYM-файл.
3. В релизных сборках храните dSYM и добавляйте их в систему обработки крашей (Sentry, Crashlytics) для автоматической символики.

Быстрое руководство по отправке отчёта разработчику

• Соберите файл .crash (в Консоли: правой кнопкой — Export). Укажите версию приложения и шаги для воспроизведения.
• Приложите логи приложения (если есть) и системный ленток (Console logs) с временной меткой.
• Укажите модель Mac, версию macOS и какие сторонние плагины/расширения установлены.

Пример простого диагностического дерева

flowchart TD
  A[Пользователь присылает .crash] --> B{Имеется ли dSYM?}
  B -- Да --> C[Симболизировать стек]
  B -- Нет --> D[Попросить dSYM или логи]
  C --> E{Стек указывает на код приложения?}
  E -- Да --> F[Анализировать функцию и исправлять]
  E -- Нет --> G[Проверить сторонние библиотеки и окружение]

Что делать, если вы не разработчик, но хотите помочь

• Соберите файл .crash и опишите шаги воспроизведения как можно точнее.
• Укажите, какие действия выполнялись в приложении и какие файлы были открыты.
• Если проблема началась после обновления macOS или приложения — укажите это.

Заключение

Отчёты об авариях на macOS содержат концентрированную информацию: кто упал, когда, и почему. Для разработчиков это основной инструмент локализации ошибок; для пользователей — источник данных для передачи в техподдержку. Даже если отчёт кажется непонятным, сохраняйте файл и прикладывайте его к обращению: он часто ускоряет диагностику.

Важно: сохраняйте dSYM и логи при подготовке релизов — это спасает часы на трассировке сложных падений.

Краткое резюме ниже.

Важно: если вы работаете с конфиденциальными данными, проверьте отчёт на чувствительную информацию перед отправкой третьим лицам.

Краткое резюме

• Нужные поля: Process, Exception Type, Crashed Thread, Backtrace.
• Без dSYM стек может быть нечитабельным — храните dSYM для релизов.
• Для многопоточных и проблем с памятью используйте Sanitizers.
• Для пользователей: снимите .crash и приложите шаги воспроизведения при обращении в поддержку.

Короткий глоссарий

• dSYM — файл отладочных символов для символики стеков.
• Symbolication — процесс замены адресов в backtrace на имена функций.
• SIGSEGV/SIGABRT — POSIX-сигналы, обозначающие разные типы аварий.