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

[Igor_Sib]

Как вовремя! Я как раз смотрел на крэш-лог с первого iPad, думал как к нему подступиться. Теперь вижу (jettisoned), понимаю что в переводе на человеческий это Out of memory. Спасибо, автор!

[f1int]

Спасибо за перевод! )
Вот перевел бы кто все статьи raywenderlich.com и собрал бы в одном месте…

[blackray]

Спасибо за перевод! На raywenderlich.com еще множество интересного материала

[wildfish]

Пожалуйста! Обязуюсь и дальше выкладывать переводы с RayWenderlich.

[Biga]

Статья про крэшлоги и ни слова про dwarfdump? Нет пути!

Применение этой замечательной команды:
dwarfdump --lookup $[0x1000 + 899296] --arch armv7 YourApp.app.dSYM
Где число 899296 надо брать в крэшдампе из конца строки (после плюса):
7 YourApp 0x001d28e0 0xf7000 + 899296

0x1000 — это смещение сегмента кода, его можно найти командой
otool -arch armv7 -l YourApp.app/YourApp | grep '^ segname __TEXT' -A1
Впрочем, похоже, оно всегда одинаковое — 0x1000.

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

Вот что мы имеем в обычном крешлоге:

0 libsystem_c.dylib 0x38314b54 strlen + 28
1 YourApp 0x0012fba3 length (char_traits.h:257)
2 libdispatch.dylib 0x36852793 _dispatch_call_block_and_release + 11

Не очень понятно, куда копать.

А вот, что можно узнать при помощи dwarfdump (сильно сокращено и интерпретировано, в том числе при помощи утилиты c++filt):

compile_unit: /Users/user/work/myapp/Classes/GCData.mm
subprogram:
  decl_file: /Users/user/work/myapp/Classes/GCData.mm:
  decl_line: 534 (это начало блока в obj-c)
  ...
  inlined_subroutine: std::string::operator=(char const*)
    call_file: /Users/user/work/myapp/Classes/GCData.mm
    call_line: 550
       в коде это  std::string name = [[player alias] UTF8String];
    
    inlined_subroutine: std::string::assign(char const*)
    ...
      inlined_subroutine: std::string::length(char const*)
      где оно и упало. Похоже, [player alias] оказался nil или что-то такое.

Теперь понятно, что и где исправлять.

[Biga]

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

[Yan169]

Мы используем crashlytics

[Igor_Sib]

Очень интересно, можете ли рассказать подробнее?

Это отражается на быстродействии программы?

[Biga]

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

У crittercism отправка данных о крэше выполняется при следующем запуске приложения — у такого решения есть и минусы, и плюсы. В других фреймворках это может быть сделано по-другому (в ранних версиях crittercism пытался отправить данные сразу после крэша).

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

[SOb_S]

> попросите прислать вам аварийные журналы по почте

Ну или объясните, что Settings -> General -> Diagnostics & Usage -> Automatically Send — это как раз и есть та галочка, которая отвечает за появление логов у разработчика в iTunes Connect

[nikolayschaback]

очень своевременный пост! только сейчас отправил первое свое приложение в AppStore

[i4niac]

Пост отличный, материал полезный по сути.

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

Я бы понял если бы речь шла о начинающем инди разработчике-одиночке. Ну или если бы описывались ошибки, связанные с обратной совместимостью, мало ли что упустили из виду. А тут создается впечатление что наваяли код, или вообще аутсорсили его, увидели что запускается и в срочном порядке зафигачили в AppStore.

Какая-то антиреклама. Если я теперь увижу приложения от этой компании, я подумаю несколько раз прежде чем качать, ведь теперь я знаю что там не код а хрень какая-то.

[SegaZero]

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

[Krypt]

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

[semifunctional]

Познавательно, жаль, что по этим логам почти невозможно понять причину сбоев в чужом приложении, а зачастую очень интересно.
Да, зайдите сюда пожалуйста: tsya.ru

[wildfish]

Виноват. Исправил 4 ошибки.