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

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

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

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

Статья про крэшлоги и ни слова про 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 или что-то такое.

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

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

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

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

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

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

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

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

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

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