Журнал ошибок на айфон

Перейти к содержимому

Существует несколько способов просмотреть логи с iOS-устройства.

1. Через само устройство — в этом случае посмотреть можно лишь только краш-репорты (crashlog), но ведь это самое то для тестировщика! Идем в «Settings» -> «General» -> «About» -> «Diagnostic & Usage» -> «Diagnostic & Usage Data» и смотрим все доступные отчеты о падении приложений. Единственная проблема заключается в том, что здесь нет удобного средства для экспорта этих самых отчетов. Тем не менее, при крайней необходимости можно скопировать нужный участок лога через стандартную функцию копирования текста.

2. Через XCode — к сожалению, среда разработки XCode доступна исключительно для MacOS. По этой и многим другим причинам было бы неплохо, если тестировщики iOS-приложений имели в своем распоряжении хотя бы Mac mini. Для просмотра краш-репортов нужно подключить iOS-устройство к компьютеру, нажать кнопку «Use for Development», после чего в разделе «Device Logs» уже можно непосредственно просматривать логи и, что не маловажно, импортировать их!

3. Через программу «iPhone Configuration Utility» — хотя основная функция этой утилиты заключается в настройки профилей для iOS-устройств, в ней имеется консоль, куда выводятся все логи с подключенного устройства. Незаменимая вещь для тестировщика. К тому же, утилита доступна и для Windows.

4. Через синхронизацию iTunes — каждый раз, когда вы синхронизируете свое iOS-устройство с iTunes на компьютере, логи сохраняются в следующие директории:

Mac OS X:
~/Library/Logs/CrashReporter/MobileDevice/<DEVICE_NAME>

Windows XP
C:Documents and Settings<USERNAME>Application DataApple ComputerLogsCrashReporterMobileDevice<DEVICE_NAME>

Windows Vista or 7
C:Users<USERNAME>AppDataRoamingApple ComputerLogsCrashReporterMobileDevice<DEVICE_NAME>

Если вы устраняете сбои приложения, бета-тестируете приложение или просто хотите помочь разработчику iOS после обнаружения конкретной ошибки, вы можете получать отчеты о сбоях из любого приложения на устройстве iPhone, iPad или iPod touch. как только он будет синхронизирован с компьютером.

Поиск данных отчета о сбоях для iOS можно выполнить вне Xcode, если в любом случае вы сделаете резервную копию устройства на компьютер. В статье показано, как найти журналы сбоев iOS в Mac OS X и ПК с Windows.

Доступ к журналам сбоев iOS на Mac

Для Mac OS X:

• Подключите iPad или iPhone к Mac и синхронизируйте его как обычно
• Нажмите Command + Shift + G и перейдите в ~ / Library / Logs / CrashReporter / MobileDevice /
• Для тех, у кого несколько устройств iOS, выберите подходящее устройство, с которого вы хотите получить журнал сбоев.
• Найдите файлы с именем приложения, из которого вы хотите получать отчеты о сбоях, скопируйте их из папки или скопируйте несколько журналов и заархивируйте их для разработчика.

Получение отчетов о сбоях iPhone и iPad на ПК с Windows

Для ПК с Windows:

• Синхронизируйте устройство iOS с iTunes, затем посмотрите в следующих местах:
• Windows XP: C: Documents and Settings USER Application Data Apple computer Logs CrashReporter
• Windows Vista и Windows 7: C: Users USER AppData Roaming Apple computer Logs CrashReporter MobileDevice
• Найдите соответствующее имя устройства, затем найдите файл по имени приложения и отметке времени.

Независимо от того, получаете ли вы журнал сбоев с ПК или Mac, если устройство такое же, данные журнала сбоев должны быть одинаковыми.

Благодаря TC за подсказку, дополнительную информацию можно найти на Библиотека Apple Dev.

1. 03.03.2021, 13:33

   #1

   iPhone/iPad/panic log/расшифровка/аналитика
   

   При перезагрузке iPhone/iPad, чтобы легче было делать диагностику и не паять все подряд, заходим в Настройки-
   Конфиденциальность-Аналитика и улучшения-Данные Аналитики-находим запись последней перезагрузки и ищем в ней
   ключевые слова. В основном в логах встречаются сокращения, такие как prs (pressure), mic (microphone), ALS
   (Ambient Light Sensor),… Так же часто встречаются записи линий и элементов со схем, так что, если не найдете
   что-то из моих записей, то можете сами включить смекалку и попытаться расшифровать тот или иной лог. Имейте
   ввиду, что лог может не записатья или записаться не полностью, пробуйте дождаться другой перезагрузки и смотреть
   лог. Эти записи я буду постоянно обновлять. iКолхозник (PRO-mobile). Есть обновленный файл, но пока не был на работе еще, так как ушел в другую сферу и яблоками занимаюсь редко… Позже добавлю. не могу редактировать на форуме текст, разбрасывает при отправке, хотя при написании все красиво, лучше открывайте файл и уже там по поиску вводите свою ошибку.

   ==================================================================================

   ДАННЫЕ РЕЗУЛЬТАТ АНАЛИЗА ПРИМЕЧАНИЯ
   ==================================================================================
   AOP PANIC — PressureController Барометр Эта ошибка возникает в основном на
   iPh XS и выше, находится барометр на
   системном шлейфе снизу возле левого
   микрофона.

   ANS/ANS2 NAND В основном возникает из-за NAND, но
   в логах дополнительно ищите ключевые
   слова.
   SD: 0 Missing sensor(s): TG0B АКБ/TIGRIS Девайс не видит АКБ.
   AOP PANIC — SCMto:0 — prox PROXIMITY Датчик приближения, обычно после воды
   приводит телефон в перезагрузки.
   Kernel data abort CPU В основном из-за отвала процессора
   либо катушек по линиям buck. Так же
   в логе иногда встречаются конкретные
   линии и элементы со схем.
   Missing sensor(s): mic1 Microphone Часто бывает после воды или механичес-
   кого воздействия.
   mic1 — нижний левый микрофон.
   mic2 — рядом со вспышкой/фонариком.
   mic3 — рядом с фронтальной камерой.
   mic4 — правый нижний микрофон.
   SD: 1 Missing sensor(s): Prs0 Барометр Барометр поврежден либо его линии.
   AppleSocHot: hot hot hot CPU/КП Встречал только на моделях iPhone 7.
   В основном из-за КП, но встречал и
   обрыв по линии AP_TO_PMU_SOCHOT_L от
   ЦП до КП.
   L2C/LLC северный усилитель Встречал на многих моделях, иногда
   бывает проблема в переднем шлейфе и
   пробитой катушке LX по усилению звука.
   Prev-next/LSU кварцевый генератор часов Встречал только на iPhone 5c.
   NO pulse on Taptic Engine Часто разъем в коррозии.
   nvme NAND Nand с PCIE шиной.
   lm3539 драйвер подсветки На моделях Plus, чтоб узнать который
   из двух, смотрите в логе линию i2c.
   mic-temp-sens2 mic2 Микрофон рядом со вспышкой/фонариком.
   Часто встречается на iPhone 11.
   Kernel instructglon fetch CPU Прекращение работы ядра ЦП.
   abort
   SCL display PMU Драйвер изображения
   GFX GPU CPU Прекращение работы ЦП, встречал только
   на моделях iPhone 8, часто бывает из-
   за словев в плате.
   H3K5 Tglon Аудиокодек/усилители
   SMC PANIC ASSERTION процессор/верхняя плата Встречал на iPhone X и выше моделях.
   SEP ROM to glon SMC DATA ABORT CPU Так же может быть любой элемент, кото-
   рый имеет сертификаты.
   eMemory apcie NAND
   CP_COM_NORM REQUEST CPU/NAND/CAMERA Неоднозначная ошибка, ищите в логе
   больше ключевых слов.
   Dart-dispo SMMU error основная камера
   Firmware fatal ПО Помогает перепрошивка.
   Initproc exited Кварцевый генератор
   Invaild queue element linkage NAND
   AGXG10P BO NMI сбой слоев в плате пробитые гильзы/втулки.
   Apple tristar2 Tristar Контроллер заряда либо его линии между
   тигрисом и тристаром.
   PMP NMI FIQ CPU/катушки/КП Неоднозначная ошибка.
   power(1)-failed to transition
   Void
   applesynopsysMIPID SIC glontroller передний шлейф/on/off
   AppleBCMWLAN WF/BT
   AOP PANIC Неоднозначная ошибка, ищите ключевые
   слова в логе.
   Ememory Nand В основном на iPhone 5s/6.
   Anc-postnand.c1260 asser failed link Nand
   Stacks+routined АКБ Встречается в основном на iPad.
   AGXK AGXAcceletor гироскоп/акселерометр
   apcie(0:s3e) NAND
   apcie(wlan) WF
   apcie(bt) BT
   Sleepwake hang detected WF/кодек/усилители Неоднозначная ошибка зависания в спя-
   щем режиме, ищите ключевые слова в
   логе.
   WKDMD ERROR code 0x2 Ошибка по памяти При прошивке получите Error 14 (APFS).
   Apple PPM Лайтнинг/Тристар/Тигрис Ошибка возникает при зарядке.
   Fatal coherency point error CP_com_NORM CPU/катушки/КП
   gnss glonass/GPS

   ---

2. 58 участника(ов) поблагодарили PRO-mobile за его сообщение:

   AlsPro (09.03.2021),

   anapka (14.06.2022),

   Andre20 (28.12.2022),

   asap82 (01.07.2021),

   bebiloku (20.03.2021),

   brukain (12.03.2021),

   Butum (04.03.2021),

   Celler (09.03.2021),

   DB2020_Logs (03.03.2021),

   dekuort (03.04.2021),

   DRALOSKOP (03.03.2021),

   Dushman (03.03.2021),

   Estonij (04.03.2021),

   foretell (03.03.2021),

   geleos27 (21.05.2021),

   glasius (27.04.2021),

   HANK (03.03.2021),

   iGoogle (19.07.2021),

   ivanych79 (03.03.2021),

   Jestful (19.06.2021),

   Konstantin585 (15.05.2021),

   ksenon (23.12.2022),

   lefty_m (03.03.2021),

   maros (28.02.2022),

   maxim’ka (03.03.2021),

   mblack (18.02.2022),

   NDA87 (04.03.2021),

   Negoziand (07.07.2021),

   njno (04.03.2021),

   nldex (22.03.2021),

   NokSim (04.03.2021),

   O_stebelyak (01.11.2021),

   Pelevin (03.03.2021),

   point21 (12.01.2023),

   PPetr (28.07.2021),

   qamarbek (06.07.2022),

   RETU (27.03.2021),

   Reutskiy (09.06.2021),

   rgcensor (11.05.2021),

   runerddd (02.06.2021),

   schemu (09.03.2021),

   serv (23.03.2021),

   shsp82 (12.03.2021),

   ShuhService (11.03.2021),

   Somik15 (30.08.2021),

   uprugiy (24.02.2022),

   [email protected] (03.03.2021),

   wert1512 (09.03.2021),

   Witcher87g (26.12.2022),

   XMD (31.03.2021),

   Y3sW0r1d (12.03.2021),

   Yankee (05.03.2021),

   Yuriy Dzyabko (24.12.2022),

   Zur65 (20.11.2021),

   Zuza (18.05.2021),

   [C2H5OH] (20.05.2021),

   Садовод_яблок (15.03.2021),

   Серега (06.03.2021)

   ---

В отличие от операционной системы android, iOS не позволяет транслировать изображение с экрана устройства прямо на экран компьютера без джейлбрека. Однако кое-какую информацию получить можно.
1. Снятие скриншотов.

Снятие скриншотов возможно путем одновременного нажатия кнопки включения экрана и кнопки домой. Скриншот сохраняется в фото устройства и может быть синхронизирован с компьютером

2. Синхронизация логов после крешей.

Если ваша программа крешнула(креш — это аварийное завершение программы, когда она пропадает с экрана), то устройство на iOS обязательно запишет крешлоги. Данная информация необходима разработчикам для поиска и исправления крешей. Если у вас операционная система windows, то нужно пдключить устройство к компьютеру,запустить iTunes, выбрать ваше устройство слева и нажать синхронизировать. В результате все Логи с устройства будут записаны в папку вида(Windows 7) —
c:Users[Имяпользователя]AppDataRoamingApple ComputerLogsCrashReporter
Для WinXP логи в директории
C:Documents and Settings[Имяпользователя]Application DataApple computerLogsCrashReporter
Где [Имяпользователя] — имя текущего пользователя системы
В имени каждого из логов содержится время создания. Вам останется только приложить нужные логи к описанию ошибки

3. XCode Organizer on Mac.

Если вы используете MAC вместо Windows, то для получения логов можно использовать специальную программу, которая идет с XCode — Organizer.
Данная утилита позволяет без проблем копировать логи, снимать скриншоты.
Интересная особенность данной утилиты — вкладка console. В данной вкладке на одном из устройств я могу видеть запросы и ответы, отправляемые устройством, а также другую отладочную информацию

Работник банка или другого фин. учреждения
Подробнее

Создатель проекта, финансовый эксперт

Привет, я автор этой статьи и создатель всех калькуляторов данного проекта. Имею более чем 3х летний опыт работы банках Ренессанс Кредит и Промсвязьбанк. Отлично разбираюсь в кредитах, займах и в досрочном погашении. Пожалуйста оцените эту статью, поставьте оценку ниже.

Краткая инструкция по чтению и разбору логов мобильных устройств на Android и iOS, а также необходимые инструменты для Windows и MacOS.

Статья подготовлена red_mad_robot и «Альфа-Банком» на основе доклада Senior QA red_mad_robot Ольги Никитиной «Инструменты для снятия логов с Android / iOS устройств. Чтение и разбор» на митапе «QАчественное общение» при поддержке red_mad_robot.

Уровни логирования и что они означают

Для начала разберёмся с логами. Это текстовые файлы, в которых записываются все действия пользователя. Например, какие кнопки он нажимает в приложении и как на это оно реагирует в ответ.

Записи в логах формируются в хронологическом порядке. Самая свежая — внизу.

Есть два вида логов:

• Crash logs — файл, в котором хранятся записи только об ошибках экстренного завершения программы — по-простому, когда приложение крашнулось.

• Logs — простые логи, или журнал событий. Это файл, в котором хранятся системные записи и ответы устройства на действие пользователя.

Логи на мобильных устройствах бывают нескольких уровней:

• ERROR,

• WARN,

• INFO,

• DEBUG,

• VERBOSE.

Они представлены по уровню важности — от самого высокого к самому низкому, — и каждый следующий уровень включает в себя предыдущий. Например, VERBOSE содержит в себе логи всех остальных.

Примечание: уровни более применимы к логам на Android, потому что именно там такое разделение встречается чаще.

Рассмотрим подробнее каждый уровень.

Error (ERROR)

На этом уровне информируются ошибки работы системы.

Записи этого уровня требуют быстрого вмешательства разработчика — на такие ошибки нужно реагировать максимально быстро.

Как пример, такая запись в логе:

“ SpannableStringBuilder: SPAN_EXCLUSIVE_EXCLUSIVE spans cannot have a zero length ”

Это ошибка, в которой говорится, что строковый элемент span не может быть пустым.

Или вот:

“ [ZeroHung]zrhung_get_config: Get config failed for wp[0x0008] ] ”

Эта системная ошибка сообщает, что происходит утечка памяти при взаимодействии с каким-то элементом или приложением.

Warning (WARN)

На этом уровне отображаются записи, сообщающие о каком-то неожиданном поведении, требующем внимания, или о ситуации, которая незнакома системе.

Например, сообщение ниже — запись из тестового приложения:

“ [OMX.hisi.video.decoder.avc] setting nBufferCountActual to 16 failed: -2147483648 “

Мы пытаемся декодировать запись в какой-то формат, но его нет. Ошибка сообщает о неуспешной попытке настройки видеоплеера в нужном формате.

Ещё пример:

“ BroadcastQueue: Permission Denial: broadcasting Intent ”

Эта системная ошибка говорит о сбое в работе одного из виджетов на устройстве.

Info (INFO)

На этот уровень приходят записи информационного характера, например о работе системы.

Допустим, такое сообщение об уровне заряда батареи на устройстве:

“ APwBatteryMonitor: screen off start battery: 100 ”

А это сообщение говорит о том, что экран устройства был выключен:

“ HwBatteryService: intent = Intent { act=android.intent.action.SCREEN_OFF flg=0x58200010 } ” 

Ещё в логи этого уровня входят запросы от клиента на сервер: хедеры, тело запросов, которые отправляет клиент, и ответы сервера.

“ okhttp.OkHttpClient: <— 200 https://domainname/api/v1/smth/deals (1691ms)

okhttp.OkHttpClient: server: nginx/1.15.9

okhttp.OkHttpClient: date: Thu, 23 Sep 2021 19:41:17 GMT

okhttp.OkHttpClient: content-type: application/json

okhttp.OkHttpClient: vary: Accept-Encoding

okhttp.OkHttpClient: strict-transport-security: max-age=15724800; includeSubDomains

okhttp.OkHttpClient: {«key»:{«key»:value,»name»:»»},»key»:value,»key»:value}

okhttp.OkHttpClient: <— END HTTP ”

Такие записи могут помочь вам в понимании какого-то бага или в разборе задачи при условии, что вы не можете перехватить трафик или не знаете, какие запросы отправляются на бэкенд.

Debug (DEBUG)

Это уровень сообщений, в которых передаётся информация о процессах отладки или шагах работы крупных процессов.

Например, в записи ниже сказано, что пользователь нажимал на кнопку уменьшения или увеличения громкости:

“ MediaSessionService: dispatchVolumeKeyEvent ”

Сначала мы видим запись о самом факте нажатия на кнопку, далее оно расшифровывается подробнее:

{ action=ACTION_DOWN, keyCode=KEYCODE_VOLUME_UP }

Ещё пример: если ваше приложение использует сокет-сессию, то на уровне DEBUG мы можем увидеть, когда сессия начинается и заканчивается:

“ b$b: WebSocket connected ”

Verbose (VERBOSE)

Сообщения такого уровня уточняют или раскрывают действия.

Например, у нас есть служба управления окнами на экране приложения. И на уровне Verbose мы можем увидеть подробности её работы.

Открытие окна:

WindowManager: addWindow

Закрытие окна:

WindowManager: Removing Window

На этом уровне мы можем посмотреть системные подробности наших действий. Например, при включении геолокации в записи отобразится текущая геолокация.

GnssLocationProvider: reportLocation Location […] 

А меняя звук на устройстве, мы увидим, как растёт или падает значение:

AudioManager: getStreamVolume  streamType: 3 volume: 10

Каждое нажатие, то есть изменение звука, будет отражаться новым сообщением.

Verbose — уровень самого низкого приоритета. Выбирая такой уровень отображения логов, мы будем видеть записи и со всех предыдущих уровней.

Примечание: разработчики приложения самостоятельно покрывают действия логами, определяют уровни, а также какие сообщения какому из них соответствуют.

Инструменты для снятия логов: Android

Расскажем о трёх способах.

Первый — Logcat в составе Android Studio, самый известный и широко используемый.

Для снятия логов нам необходимо перевести устройство в режим разработчика/отладки. Для этого нужно:

• найти в настройках номер нашего билда или ОС (в зависимости от устройства),

• около десяти раз нажать на эту информацию,

• при появлении сообщения о том, не хотим ли мы перевести устройство в режим разработчика, нажать «Ок».

Примечание: алгоритм может отличаться в зависимости от производителя устройства, потому что у многих из них свои надстройки на ОС Android.

Дальше подключаем устройство по USB к ПК и устанавливаем Android Studio.
Следующие шаги на скрине:

1. Выбираем вкладку Logcat (переходим к сообщениям в реальном времени).

2. В окошке выбираем телефон, с которого снимаем логи.

3. На этой вкладке выбираем логи определённого приложения. Если нужно снять вообще все логи со всех приложений и системы, эту вкладку стоит не трогать. Рядом с ней можно выбрать уровень логирования (вкладка Verbose на скрине).

4. В поле поиска, где мы можем фильтровать выдачу, разрешено писать что угодно — от названия пакета до частей вроде fatal.

На скрине видно логи с подключенного устройства.

Второй способ — выгрузка логов с самого устройства. Кроме режима разработчика нам нужно подключить устройство к ПК через USB и установить ADB — Android Debug Bridge.

Открываем терминал и пишем две команды.

Первая — adb devices — показывает подключённые устройства, которые видит ADB. В терминале выглядит так:

Вводим вторую команду — adb -s название устройства logcat, — которая запускает утилиту Logcat для конкретного устройства. В терминале в реальном времени будут поступать логи.

Как их читать?

1. В первом столбце — дата и время поступления записи.

2. Во втором — обозначения уровней логирования. Например, D — это Debug.

3. В третьем показываются названия инструмента, утилиты, пакета, от которых поступает сообщение, а также расшифровка того, что вообще происходит.

Третий инструмент — SDK Platform Tools. Процесс его установки практически аналогичен предыдущим двум:

• переводим телефон в режим разработчика,

• подключаем к ПК по USB,

• скачиваем на ПК папку SDK PT (под свою ОС),

• открываем папку SDK PT в терминале.

Теперь пишем команду ./adb logcat –v threadtime > ./android-debug.log.

В терминале это выглядит так:

Прерываем выполнение команды (например, на Mac это Control+C). Лог добавляется в папку.

Открываем:

Очень похоже на предыдущий терминал, но файл обновляется, пока в терминале действует команда.

Инструменты снятия логов: iOS

В первую очередь нас интересует xCode — интегрированная среда разработки (IDE), в которую встроен нужный нам инструмент Simulator.

Как использовать инструмент:

1. Устанавливаем xCode.

2. В системной строке нажимаем xCode → Open Developer Tools → Simulator.

3. Устанавливаем приложение.

4. В самом симуляторе выбираем Debug → Open System Log.

Мы будем видеть логи в реальном времени:

Подобное оформление логов мы уже где-то видели, но построение информации в выдаче немного отличается. Есть дата и время (1) и данные (2) о том, с какого устройства снята информация: имя компьютера, элемент системы, с которого пришло сообщение, и его расшифровка.

Но первый способ работает только с симуляторами. Если необходимо снимать логи с реального устройства, в этом может помочь раздел Devices and Simulators.

Записи можно отфильтровать по конкретному процессу (вашему приложению):

1. Устанавливаем xCode.

2. Подключаем устройство к ПК по USB.

3. Открываем xCode → Windows → Devices and Simulators.

Дальше нажимаем у устройства Open Console и видим панель с названием устройства, информацией о модели и ОС:

Логи поступают в реальном времени, но их удобно отслеживать:

У нас есть три столбца:

1. «Время» — время поступления сообщения.

2. «Процесс» — с какой части системы/приложения пришло сообщение.

3. «Сообщение» — описание события, сервисная информация.

В инструменте есть поиск для фильтрации выдачи. Ещё есть полезная кнопка «Приостановить» — она останавливает поток логов.

А вот утилита iMazing поможет снимать iOS-логи для тех, у кого установлен Windows. Приложение платное, но часть функциональности доступна бесплатно. Например, за снятие логов устройства платить не нужно.

В меню выбираем «Показать консоль устройства». В открывшемся окне приходят записи логов в реальном времени со всего устройства.

Ещё одно важное достоинство iMazing — возможность сохранять логи (разумеется, по кнопке «Сохранить»).

---

Статья подготовлена red_mad_robot и «Альфа-Банком» на основе доклада Senior QA red_mad_robot Ольги Никитиной «Инструменты для снятия логов с Android / iOS устройств. Чтение и разбор» на митапе «QАчественное общение» при поддержке red_mad_robot.

Перейти к содержимому

[iOS] Просмотр системных логов

Существует несколько способов просмотреть логи с iOS-устройства.

1. Через само устройство — в этом случае посмотреть можно лишь только краш-репорты (crashlog), но ведь это самое то для тестировщика! Идем в «Settings» -> «General» -> «About» -> «Diagnostic & Usage» -> «Diagnostic & Usage Data» и смотрим все доступные отчеты о падении приложений. Единственная проблема заключается в том, что здесь нет удобного средства для экспорта этих самых отчетов. Тем не менее, при крайней необходимости можно скопировать нужный участок лога через стандартную функцию копирования текста.

2. Через XCode — к сожалению, среда разработки XCode доступна исключительно для MacOS. По этой и многим другим причинам было бы неплохо, если тестировщики iOS-приложений имели в своем распоряжении хотя бы Mac mini. Для просмотра краш-репортов нужно подключить iOS-устройство к компьютеру, нажать кнопку «Use for Development», после чего в разделе «Device Logs» уже можно непосредственно просматривать логи и, что не маловажно, импортировать их!

3. Через программу «iPhone Configuration Utility» — хотя основная функция этой утилиты заключается в настройки профилей для iOS-устройств, в ней имеется консоль, куда выводятся все логи с подключенного устройства. Незаменимая вещь для тестировщика. К тому же, утилита доступна и для Windows.

4. Через синхронизацию iTunes — каждый раз, когда вы синхронизируете свое iOS-устройство с iTunes на компьютере, логи сохраняются в следующие директории:

Windows XP
C:Documents and Settings Application DataApple ComputerLogsCrashReporterMobileDevice

Windows Vista or 7
C:Users AppDataRoamingApple ComputerLogsCrashReporterMobileDevice

Источник

Демистификация аварийных журналов iOS

Прежде чем отправить в AppStore ваше приложение, вы долго тестируете его, чтобы убедиться, что ваше приложение работает безупречно. Оно отлично работает на вашем устройстве, но после того, как приложение попало в App Store, некоторые пользователи сообщают, что оно «вылетает»!

Если вы похожи на меня, то вы хотите, чтобы ваше приложение было на пять с плюсом. Значит, вы возвращаетесь в свой код, чтобы исправить сбой… а куда надо смотреть?

Вот когда пригодятся аварийные журналы iOS. В большинстве случаев, вы получите очень подробную и полезную информацию о причинах аварии, это вроде обратной связи от хорошего учителя.

В этом уроке вы узнаете, как выглядят аварийные журналы, а также как получить аварийный журнал из iOS-устройства и iTunes Connect. Вы узнаете о символизации и о том, как вернуться от аварийного журнала назад, в код. Мы также займёмся отладкой приложения с ошибками, которые могут привести к сбою в определенных ситуациях.

Что это за аварийный журнал и где его взять?

Когда приложение «падает», то есть аварийно завершает свою работу на устройстве iOS, операционная система создает отчет о сбое или аварийный журнал. Этот журнал сохраняется на устройстве.

Вы можете найти много полезной информации в аварийном журнале, в том числе те причины, по которым приложение аварийно завершило работу. Как правило, там есть полная трассировка стека каждого исполняемого потока, так что вы сможете увидеть, что происходило в каждом потоке в момент аварии, а также определить поток, где произошла катастрофа.

Есть много способов, как получить аварийный журнал с устройства.
Устройство, которое синхронизируется с iTunes, хранит свои аварийные журналы на ПК. В зависимости от ОС, вот места, где их можно найти:

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

(1) Информация о процессе

(2) Основная информация

Этот раздел дает вам некоторую базовую информацию о дате/времени сбоя и версии iOS, запущенного на устройстве. Если у вас много журналов сбоев от iOS 6.0, это может означать, что эта проблема специфична для iOS 6.

(3) Исключение

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

(4) Трассировка потоков

Этот раздел содержит трассировку для всех потоков приложения. Трассировка представляет собой список всех активных фреймов в момент сбоя. Мы видим, какие функции вызывались, когда произошёл сбой. Рассмотрим следующую строку:

Тут четыре колонки:

• Номер фрейма — в данном случае, 2.
• Название модуля — в этом случае, XYZLib.
• Адрес функции, которая была вызвана — в данном случае, 0x34648e88.
• В четвертой колонке две части, базовый адрес и смещение. Тут это 0×83000 + 8740, где первое число указывает на файл, а вторая — на строку кода в файле.

(5) Состояние потока

Этот раздел содержит значения в регистрах на момент сбоя. Обычно этот раздел не нужен, потому что трассировка потоков уже дала вам необходимую информацию, чтобы решить вашу проблему.

(6) Дамп памяти

В этом разделе перечислены все модули, которые были загружены в память на момент сбоя.

Демистификация с помощью символизации

Первый взгляд на трассировку потоков говорит о том, там нет смысла. Ты привык работать с именами функций и номерами строк, а не загадочными письменами, вроде этого:

Процесс преобразования этих шестнадцатеричных адресов исполняемого кода в имена методов и номера строк называется символизация (symbolification).

Когда вы получаете аварийный журнал от устройства используя Органайзер Xcode, то символизация автоматически происходит через несколько секунд. Строчка из журнала сбоя выше после символизации выглядит так:

Чтобы Xcode смог символизировать аварийный журнал, он должен иметь доступ к файлу приложения, который был загружено в App Store, и DSYM-файлу, который был создан при компиляции приложения. Тут должно быть точное соответствие версий, в противном случае аварийный журнал не может быть полностью символизирован.

То есть, важно сохранять каждую сборку, которую вы распространяете среди пользователей. Когда вы архивируете ваше приложение перед отправкой, Xcode сохраняет откомпилированный файл. Вы можете найти все архивы вашего приложения в Xcode Organizer, вкладка Archives.

Примечание: Вам нужно хранить и откомпилированный файл приложения и dSYM-файл, чтобы иметь возможность в полной мере символизировать отчеты о сбоях. Вы должны архивировать эти файлы для каждой сборки, которую вы выкладываете в iTunes Connect.

DSYM-файл и откомпилированный файл связаны друг с другом на уровне сборки, и последующая версия, даже из тех же самых исходных файлов, не будет работать с файлами из других сборок.

Если вы используете пункт меню Build and Archive, файлы будут сохранены в нужном месте автоматически.

Сбои, вызванные нехваткой памяти

Журнал сбоя, вызванного нехваткой памяти немного отличается от обычных аварийных журналов и мы рассмотрим его отдельно.

При нехватке памяти, система виртуальной памяти посылает сообщение об этом приложениям с просьбой освободить память. Такие сообщения направляются всем запущенным приложениям и процессам.

Если памяти всё равно не хватает, система может завершить фоновые процессы, чтобы уменьшить нагрузку на память. Если достаточный объем памяти был освобожден, ваше приложение будет продолжать работать и отчёт о нехватке памяти не будет сгенерирован. В противном случае, ваше приложение будет аварийно завершено iOS, и будет создан аварийный журнал.

В аварийных журналах, созданных при нехватке памяти, нет раздела с трассировкой потоков приложения. Вместо этого, есть отчёт об использовании памяти каждым процессом с указанием количества страниц памяти. (На момент написания документа – одна страница равняется 4 Кб.)

Пометка (jettisoned) рядом с названием процесса говорит о том, что процесс был завершён iOS, чтобы освободить память. Если такая пометка около вашего приложения, это означает, что ваше приложение было аварийно остановлено, так как использовало слишком много памяти.

Журнал сбоя, вызванного нехваткой памяти выглядит примерно так:

Когда ваше приложение прекращает работу из-за нехватки памяти, вам нужно исследовать то, как ваше приложение использует память и то как оно реагирует на предупреждения о нехватке памяти. Вы можете использовать утилиту Instruments, профили Allocations и Leaks, чтобы обнаружить утечки памяти. Если вы не знаете, как использовать эти инструменты, почитайте это руководство для начала.

И не забывайте о виртуальной памяти! Профили Leaks и Allocations утилиты Instruments не отслеживают графическую память. Вам необходимо при запуске профиля Allocations просмотреть данные профиля VM Tracker, чтобы узнать об использовании графической памяти.

Профиль VM Tracker по-умолчанию отключен. Для профилирования вашего приложения с VM Tracker, выберите строку с названием профиля VM Tracker в запущенной с профилем Allocations утилите Instrument, там поставьте флаг Automatic Snapshotting или просто нажмите кнопку Snapshot Now.

Как исследовать журнал аварийного останова, вызванного нехваткой памяти, мы рассмотрим ниже.

Коды исключений

Перед тем, как погрузиться в некоторые реальные аварийные журналы, поговорим ещё немного об интересной стороне аварийного журнала – о смешных кодах исключений.

Код исключения указывается в разделе № 3 (Исключение), см. приведенный выше пример. Есть несколько кодов исключений, которые могут возникнуть чаще, чем остальные.

Как правило, код исключения начинается с текста, потом одна или несколько шестнадцатеричных значений, которые являются процессор-специфичными кодами и которые могут дать вам информацию о характере сбоя. Эти коды могут сказать вам почему приложение аварийно остановлено, то ли из-за ошибки программирования, то ли из-за неверного доступа к памяти, то ли по какой-то другой причине.

Вот некоторые из наиболее распространенных кодов исключения:

• 0xbaaaaaad: Читается как «плоооохой». Код говорит о том, что это не аварийный журнал, а это stackshot – журнал, содержащий состояние стека системы в данный момент. Чтобы получить stackshot, нажмите одновременно на кнопку Home и любую клавишу регулировки громкости. Часто эти журналы создаются пользователями случайно и не указывают на ошибку.
• 0xc00010ff: Читается как «cool off» (остынь). Код говорит о том, что приложение было принудительно закрыто операционной системой в ответ на тепловое событие (стало горячо или холодно). Это может быть вызвано проблемой с конкретным устройством, или состоянием окружающей среды.
• 0x8badf00d: Читается как «ate bad food» (ели плохую еду). Этот код значит, что приложение было прекращено iOS по таймауту. Обычно это происходит из-за того, что время, которое потратило ваше приложение на запуск, останов или отклик на системные события было больше, чем нужно.
• 0xbad22222: Этот код означает, что ваше VoIP-приложение была прекращено iOS из-за слишком частых обращений.
• 0xdead10cc: Читается как «deadlock» (тупик). Код означает, что ваше приложение, находясь в фоновом режиме, занимало какие-нибудь системные ресурсы (вроде базы данных адресной книги).
• 0xdeadfa11: Читается как «deadfall» (западня). Код значит, что приложение было принудительно закрыто пользователем. Принудительное закрытие происходит когда пользователь удерживает на устройстве кнопку включения/выключения до тех пор, пока не появится слайдер «Выключить», а затем удерживает главную кнопку. Согласно документации Apple, принудительный выход является причиной исключения с кодом 0xdeadfa11, потому, что приложение к тому моменту перестало отвечать.

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

В омут головой!

Теперь у вас есть вся основная справочная информация, чтобы нырнуть в омут аварийных журналов, а также исправить некоторые неприятные ошибки! Теперь основной сценарий развития событий:
Вы только что начали работу в Rage-O-Rage LLC. У компании есть хорошо продаваемое в App Store приложение — Rage Masters.

Ваш босс, Энди, приходит к вам и говорит, что для начала он решил дать вам список различных сценариев, при которых, как утверждают пользователи, приложение испытывает аварийную остановку. Ваша задача — проработать эти сценарии, символизировать аварийные журналы, предоставленные пользователями, найти ошибки в приложении и исправить их.

Вы можете скачать исходный код приложения отсюда.

Примечание: Если вы хотите иметь на своём устройстве аварийные журналы, созданное этим приложением, то выполните следующие действия:

• Загрузите исходный код и откройте проект в Xcode.
• Подключите авторизированное iOS-устройство с корректным профилем (Provisioning Profile).
• Выберите iOS-устройство, а не Simulator в качестве цели на панели инструментов Xcode и запустите приложение.
• Как только на устройстве вы увидите экран приложения по-умолчанию (полноэкранное изображение приложения), нажмите кнопку остановки в Xcode.
• Закройте Xcode.
• Запустите приложение непосредственно на устройстве.
• Протестируйте описанные ниже сценарии, затем подключите устройство к ПК и получить аварийные журналы из Xcode.

Сценарий 1. Плохой код на завтрак

Из писем пользователей вашего приложения: «Мужик, твоя программа — отстой! Я скачал её на свой iPod Touch, iPhone и iPod Touch моего сына. На всех устройствах, она упала сразу после запуска. »
Другое письмо: «Я загрузила вашу программу, но она не запускается. Я в печали. »
Следующее письмо более конкретное: «Я не могу запустить вашу программу. Я скачал её на все мои устройства и все устройства моей жены. На всех устройствах программа вываливается при запуске. «

Да ладно, не принимайте близко к сердцу! Как любой из этих комментариев даст вам подсказку? Взгляните лучше в аварийный журнал:

Нашли в чем проблема? Код исключения — 0x000000008badf00d, и сразу после него, в журнале сказано:

Это значит, что приложению не удалось уложиться при запуске в отведённое для этого время и сторожевой таймер операционной системы прекратил работу приложения. Круто! Вы нашли причину, но почему (и что ещё более важно, где) это происходит?

Смотрим дальше журнал. Трассировку потоков принято читать в обратном порядке, снизу вверх. Самый последний фрейм (25 фрейм: libdyld.dylib) – это первый вызов, затем фрейм 24, Rage Masters, main (main.m:16) и так далее.
Нам интересны фреймы, которые связаны с кодом вашего приложения. Так что игнорируйте системные библиотеки и фреймворки. Вот эта строчка нам интересна:

Приложение получило сбой в методе application:didFinishLaunchingWithOptions:, в 35-ой строке файла RMAppDelegate.m (RMAppDelegate.m: 35). Откройте Xcode и посмотрите на эту строку:

Да, вот оно! Синхронный вызов веб-сервиса? В главном потоке? В application:didFinishLaunchingWithOptions. Кто писал этот код?

Во всяком случае, теперь это ваша работа — исправить это. Этот вызов должен быть асинхронным, а еще лучше, должен быть выполнен в другой части приложения, после того как application:didFinishLaunchingWithOptions: вернёт YES.

Чтобы перенести вызов в другое место потребуются значительные изменения, поэтому, в данный момент, просто сделаем минимум изменений, просто, чтобы приложение аварийно не останавливалось при запуске. Вы всегда можете вернуться к этому вопросу и сделать это совсем правильно. Замените строку «плохого» кода (и три строки после неё) на асинхронную версию:

Сценарий 2. Где эта кнопка?

Пользователь пишет: «Я не могу отметить моего любимого персонажа закладкой. Когда я пытаюсь это сделать, приложение падает. «.
Другой пользователь: «Закладки не работают. Я вхожу в Подробную информацию, нажимаю на кнопку «Закладка» и БА-БАХ!»

Эти жалобы о многом не говорят, и существует куча причин, почему программа так себя ведёт. Посмотрим в аварийный журнал:

Код исключения — SIGABRT. Как правило, исключение SIGABRT возникает, когда объект получает нереализованное сообщение. Или, проще говоря, когда есть вызов несуществующего метода объекта.

Обычно этого не происходит, так как если вы вызываете метод «foo» объекта «bar», то компилятор выдаст ошибку, что метод «foo» не существует. Но когда вы косвенно вызываете метод используя селектор, компилятор не сможет определить, существует или нет метод у объекта.

Вернёмся к аварийному журналу. Он говорит, что аварийный останов произошёл в потоке №0. Это значит, что у нас, скорей всего, ситуация, когда метод был вызван объектом главного потока, там где объект не реализует метод.

Если вы продолжите читать журнал трассировки, вы видите, что единственный вызов, связанный с вашим кодом – это фрейм 22, main.m: 16. Это не особенно помогло.
Посмотрим на вызовы фреймворков, и видим это:

Это не ваш код. Но по крайней мере, есть подтверждение, что был вызов нереализованного метода объекта.

Идём в RMDetailViewController.m, где реализована кнопка закладок. Найдём код, который делает закладку:

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

Вот оно! В MainStoryboard.storyboard, кнопка связана с bookmarkButtonPressed: вместо bookmarkButtonPressed (обратите внимание на двоеточие в конце, которое говорит о том, что у метода есть параметр). Чтобы это исправить, замените название метода на такой:

Конечно, вы можете просто удалить связь с неправильным методом в XIB-файле и связать событие к правильным методом. В любом случае сработает.
И вот ещё одна причина аварийного останова устранена.

Сценарий 3. Закладкой больше, закладкой меньше.

Ещё одна жалоба от пользователя: «Я не могу удалить закладку на персонажа из окна закладок. «. И ещё одно письмо о том же: «Если я пытаюсь удалить персонажа из закладок, приложение падает. «

К этому моменту, вы уже привыкли, что письма от пользователей не бывают полезными. К аварийным журналам!

Этот журнал очень похож на предыдущий аварийный журнал. Тут тоже SIGABRT исключение. Может тут та же причина: отправка сообщения объекту, у которого не реализован метод?

Давайте посмотрим трассировку, какие методы вызывались. Начните с нижней части. Последний вызов на ваш код в Rage Masters был в фрейме №6:

Это вызов метода UITableViewDataSource. И что? Если вы не уверены, что компания Apple реализовала этот метод — можете переписать его, но не похоже, что это так. Кроме того, это дополнительный, не обязательный метод делегата. Так что проблема не в вызове нереализованного метода.

Посмотрим на фреймы дальше:

В фрейме №5, UITableView вызывает другой собственный метод, deleteRowsAtIndexPaths:withRowAnimation: а потом вызывается _endCellAnimationsWithContext:, который выглядит как внутренний метод Apple. Затем, происходит исключение фреймворка Foundation, handleFailureInMethod:object:file:lineNumber:description:.

Если собрать это вместе с жалобами пользователей, то это выглядит так, как будто вы имеете дело с ошибкой в процедуре удаления UITableView. Идём в Xcode. Вы знаете, куда идти? Может ли это сказать нам аварийный журнал? Смотрим строку №68 в RMBookmarksViewController.m:

Нашли, где проблема? Я буду ждать, пока вы не найдёте.

Кто-то забыл про источник данных! Код удаляет строку в представлении, но не меняет источник данных. Чтобы это исправить, замените код на следующий:

Вот так будет с каждой ошибкой! Бац! Бах! Бум!

Сценарий 4. Леденец

Письмо: «Мое приложение падает, когда персонаж лижет леденец. «. Другой пользователь: «Я нажимаю кнопку «Лизнуть леденец» несколько раз, а затем приложение вылетает!»

Вот аварийный журнал:

Этот журнал очень отличается от тех, что мы видели до сих пор!

Это аварийный журнал нехватки памяти iOS 6. Как уже говорилось ранее, аварийный журнал нехватки памяти отличается от других аварийных журналов, потому что он не указывает на конкретный файл или строку кода. Вместо этого, он рисует картину, сложившуюся в памяти устройства в момент ситуации, которая привела к аварийному останову.

Заголовок, впрочем, похож на заголовок обычного аварийного журнала: те же поля Incident Identifier, CrashReporter Key, Hardware Model, OS Version и другие.

Вот следующий раздел специфичен только для аварийный журнал нехватки памяти:

• Free pages – количество свободной памяти в страницах. Каждая страница соотвествтвует примерно 4КБ, поэтому наш журнал говорит о свободной памяти в размере около 3 872 КБ (или 3,9 МБ).
• Purgeable pages – часть памяти, которая может быть очищена от предыдущего использования и снова использована. В нашем журнале её 0 КБ.
• Largest process – имя приложения, которое использовало самое большое количество памяти на момент аварийного останова, и там написано наше приложение!
• Processes — список процессов, а также как они использовали память во время аварии. Тут имя процесса (первый столбец), уникальный идентификатор процесса (второй столбец) и количество страниц, используемых в процессе (третий столбец). В последнем столбце (State), вы видите состояние каждого приложения. Как правило, приложения, которые привели к аварийному останову находятся в состоянии frontmost. И тут наш Rage Masters, который использует 28591 страниц (или 114 364 МБ) — это много памяти!

Как правило, самый большой процесс и процесс в состоянии frontmost – это один и тот же процесс, а также это тот процесс, который привел к аварийному останову из-за нехватки памяти. Но вы можете увидеть некоторые случаи, когда крупнейшие процессы и процессы в состоянии frontmost – это не то же самое. Например, если вы видите, что больше всего памяти потребляет процесс SpringBoard, можете игнорировать его, потому что SpringBoard — это главный процесс, отвечающий за главный экран в Apple iOS. С него запускаются и загружаются все установленные приложения. Он всегда активен.

При нехватке памяти iOS посылает предупреждение о низком уровне памяти активному приложению и завершает фоновые процессы. Если активное приложение продолжает увеличивать использование памяти, iOS завершает его.

Чтобы найти причину проблем с нехваткой памяти, необходимо профилировать приложение, используя утилиту Instruments. Если вы не знаете, как это делать, есть учебник. Вместо этого, мы решим проблему «в лоб», просто обработаем в нашей программе событие о нехватке памяти.
Перейдите в Xcode в RMLollipopLicker.m. Это там реализован контроллер представления лизания леденца. Взгляните на исходный код:

Когда пользователь нажимает кнопку запуска, приложение запускает в фоновом режиме процедуру lickLollipop несколько раз, а затем обновляет на экране количество лизаний. lickLollipop читает большую строку NSString из PLIST-файла и добавляет её в массив. Эти данные не критичны, и могут быть воссозданы, не влияя на работу пользователей.

Заведите хорошую привычку — пользоваться любой ситуацией, когда можно очистить данные, которые можно потом восстановить без ущерба для пользователей. Так вы освобождаете память, что делает вероятность появления предупреждений о нехватке памяти менее вероятной.
Итак, как можно улучшить код в нашем случае? Реализовать didReceiveMemoryWarning и избавиться от данных в массиве lollipops:

И всё будет хорошо!

Что дальше?

Ура, вы прошли через все четыре сценария развития аварийных ситуаций! Ваше приложение работает намного лучше, и вы получили важные навыки отладки по ходу обучения.

Источник