Символизирующий отчет о сбое iOS 7 с использованием Flurry Crash Analytics

Недавно я нажал обновление iOS 7 для своего приложения и реализовал Flurry Analytics с включенной отчетностью о сбоях. Недавно я заметил, что некоторые пользователи испытывают сбои. Используя Flurry, я могу получить трассировку стека в момент, когда мое приложение разбилось, чтобы отследить проблему.
Ну, я, конечно, знаком с отчетами о сбоях и уже исправленными ошибками, использующими их раньше, получая их из iTunes Connect или почты и просто символизируя их в Xcode. Однако мне не удается это сделать с помощью Flurry.

Что я пробовал:
При просмотре трассировки стека непосредственно на Flurry это я получаю: Flurry stack trace Как вы можете видеть, многие строки прекрасно символизируются, другие символизируются <redacted>. Некоторые исследования узнали, что Apple лишила много отладочных символов в iOS 6 и 7.
Первое, что я пробовал, - это загрузить мой собственный файл dSYM. Flurry сообщила, что файл dSYM был сохранен, а отчеты о сбоях были снова отображены с использованием файла dSYM. Трассировка стека была, тем не менее, такой же, как и без dSYM.
Без проблем, подумал я, я мог бы просто попытаться загрузить отчет о сбоях и символизировать его с помощью Xcode. Нажатие на загрузку дает мне файл (без расширения, поэтому я переименовал его в .crash) с этим контентом:

Hardware Model:      iPhone3,1
Process:         RadioPlayer [2965]
Path:            /var/mobile/Applications/E4DD7DA6-4450-4538-A1E2-AE23139FAC10/RadioPlayer.app/RadioPlayer
Identifier:      *******
Version:         1.2.0
Code Type:       ARM
Parent Process:  launchd [1]

Exception Type:  SIGSEGV
Exception Codes: SEGV_ACCERR at 0x548a000
Crashed Thread:  2

Thread 0:
0   libsystem_kernel.dylib              0x3aa67a8c _mach_msg_trap + 20
1   CoreFoundation                      0x3015e7cb <redacted> + 154
2   CoreFoundation                      0x3015cf37 <redacted> + 854
3   CoreFoundation                      0x300c7ce7 _CFRunLoopRunSpecific + 522
4   CoreFoundation                      0x300c7acb _CFRunLoopRunInMode + 106
5   GraphicsServices                    0x34da0283 _GSEventRunModal + 138
6   UIKit                               0x32969a41 _UIApplicationMain + 1136
7   RadioPlayer                         0x000dfb9b __mh_execute_header + 23451
8   libdyld.dylib                       0x3a9c3ab7 <redacted> + 2

Thread 1:
0   libsystem_kernel.dylib              0x3aa6783c _kevent64 + 24
1   libdispatch.dylib                   0x3a9a23f3 <redacted> + 38

Thread 2 Crashed:
0   vImage                              0x2f19d7dc <redacted> + 139
1   vImage                              0x2f1874ff _vImageFlatten_RGBA8888 + 378
2   vImage                              0x2f26e799 <redacted> + 40
3   vImage                              0x2f27d7c3 <redacted> + 674
4   vImage                              0x2f27d365 _vImageConvert_AnyToAny + 1300
5   ImageIO                             0x30efd9e7 <redacted> + 858
6   ImageIO                             0x30ef8c3b <redacted> + 2754
7   ImageIO                             0x30ef8173 <redacted> + 102
8   ImageIO                             0x30ef8057 _CGImageDestinationFinalize + 66
9   UIKit                               0x32a8a611 _UIImageJPEGRepresentation + 520
10  MediaPlayer                         0x31435319 -[MPMediaItemArtwork imageDataWithSize:atPlaybackTime:] + 36
11  MediaPlayer                         0x31435387 -[MPMediaItemArtwork albumImageDataWithSize:] + 42
12  MediaPlayer                         0x31494f0d -[MPNowPlayingInfoCenter _pushNowPlayingInfoAndRetry:] + 824
13  libdispatch.dylib                   0x3a99ed7b <redacted> + 10
14  libdispatch.dylib                   0x3a99f2f3 <redacted> + 378
15  libdispatch.dylib                   0x3a99f75b <redacted> + 38
16  libdispatch.dylib                   0x3a9b18f9 <redacted> + 76
17  libdispatch.dylib                   0x3a9b1b79 <redacted> + 56
18  libsystem_pthread.dylib             0x3aae0dbf __pthread_wqthread + 298
19  libsystem_pthread.dylib             0x3aae0c84 _start_wqthread + 8


// The file continues like this listing the other threads and overview of binary images.
// I however didn't paste that part here since I don't think it useful.

Теперь я попробовал просто перетащить этот файл в организатор Xcode и импортировать журналы устройств. Оба ничего не сделали. В списке не появилось новое объявление устройства или что-то еще.
Следующий шаг: попытка символизировать журнал сбоев вручную, используя atos. Я скопировал содержимое dSYM в рабочий каталог и т.д., А затем попробовал эту команду

xcrun atos -arch armv7 -o RadioPlayer 0x31435387`

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

Кто-нибудь может помочь мне в этом вопросе? Мне очень хотелось бы символизировать эти символы <redacted>, так как это, безусловно, поможет мне исправить ошибку, которая приведет к этим сбоям. Спасибо!

Ответы

Ответ 1

Я заметил, что для того, чтобы перетащить отчет о сбое Flurry в XCode Organizer, вам необходимо:

  • Переименуйте файл в .crash

  • Добавьте строку идентификатора инцидента в верхней части отчета. Это похоже на GUID, поэтому вы можете поместить что-нибудь уникальное или создать один онлайн, например

    Идентификатор инцидента: D1D6CA1F-EC87-4677-9366-401BE050B2C8

  • Добавьте строки версии iOS и Crash Report (чуть выше типа исключения), например

    Версия ОС: iOS 7.1.1 (11D201)

    Версия отчета: 104

Ответ 2

  • <redacted> - оптимизация iOS только для системных символов.
  • Загрузка вашего приложения dSYM не изменяет ничего, поскольку в нем содержатся только символы приложения, а не системные символы iOS требуемой архитектуры процессора.
  • Чтобы символизировать их локально, вам нужно иметь точные системные символы или версию iOS и архитектуру, которые создали сбой.
  • Использование atos для обозначения системного символа с вашим бинарным приложением /dSYM не работает (как указано выше)
  • Получение символа только путем передачи по адресу в стеке стека никогда не работает, вам также необходимо передать адрес загрузки соответствующего двоичного файла (который можно найти в разделе двоичных изображений, первый адрес в строке двоичный файл)
  • В примере atos вы пытаетесь указать адрес, который уже показывает правильные символы в трассировке стека.
  • Перетаскивание отчета о сбое в организатор Xcode должно уже символизировать отчет, если у вас есть доступные символы, и вам не придется выполнять инструкции по управлению.
  • Похоже, что у Flurry нет символов iOS на своем сервере для разрешения этих символов.

Таким образом, пример для 0x3a99ed7b библиотеки libdispatch.dylib:

xcrun atos -arch armv7 -o PathToLibrary -l LoadAddressOfLibrary 0x3a99ed7b

Корневой путь для iOS-символов на вашем Mac: ~/Library/Developer/Xcode/iOS DeviceSupport/`с подкаталогом для каждой версии iOS.

Итак, простое решение: перетащите отчет о сбое в запись Device Logs в организаторе Xcode и надейтесь, что у вас есть все необходимое. Если это не удаляет хотя бы некоторые из строк <redacted>, вам не хватает символов iOS, и шаги руководства также не будут работать.

Ответ 3

это сработало для моих журнальных журналов http://ipartymobile.com/how-to-find-your-bug-from-ios-crash-logs/ не нужно было добавлять что-либо к сообщению о сбоях, просто занимал адреса памяти и подключался к этот формат "xcrun atos -arch armv7 -o MyApp 0x0000000"