Символизирующие отчеты о сбоях приложения iPhone

Я пытаюсь символизировать сообщения о сбоях моего приложения для iPhone.

Я получил отчеты о сбоях из iTunes Connect. У меня есть двоичный файл приложения, который я отправил в App Store, и у меня есть файл dSYM, который был сгенерирован как часть сборки.

У меня есть все эти файлы вместе в одном каталоге, который индексируется в центре внимания.

Что теперь?

Я попытался вызвать:

symbolicatecrash crashreport.crash myApp.app.dSYM

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

Я делаю что-то неправильно?

Шаги для анализа отчета о сбое от Apple:

1. Скопируйте файл выпуска .app, который был помещен в магазин приложений, файл .dSYM, созданный во время выпуска, и отчет о сбое, полученный из APPLE, в ПАПКУ .

2. Откройте приложение терминала и перейдите в созданную выше папку (используя cdкоманду)

3. Беги atos -arch armv7 -o APPNAME.app/APPNAME MEMORY_LOCATION_OF_CRASH. Расположение памяти должно быть тем, в котором приложение терпело крах согласно отчету.

Пример: atos -arch armv7 -o 'APPNAME.app'/'APPNAME' 0x0003b508

Это покажет вам точную строку, имя метода, которое привело к сбою.

Пример: [classname functionName:]; -510

Символизирующий МФА

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

Запись

Это может работать только в том случае, если в двоичном файле приложения нет символов. По умолчанию в сборках релиза отсутствуют символы. Мы можем изменить его в настройках сборки проекта "Разобрать символы отладки во время копирования" на NO.

Подробнее см. Этот пост

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

Есть 3 ресурса, которые должны быть соединены вместе, когда символизирует журнал сбоев:

1. Сам файл журнала сбоя (т.е. example.crash ), либо экспортированный из органайзера XCode, либо полученный из iTunes Connect.
2. .appПакет (то есть example.app) , что само по себе содержит приложение бинарного принадлежащий к аварии журнала. Если у вас есть .ipaпакет (то есть example.ipa), то вы можете извлечь .appпакет, распаковав .ipaпакет (т.е. unzip example.ipa). После этого .appпакет находится в извлеченномPayload/ папке.
3. .dSYMПакет , содержащий символы отладки (то есть example.app.dSYM)

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

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

...
Binary Images:
0xe1000 -    0x1f0fff +example armv7  <aa5e633efda8346cab92b01320043dc3> /var/mobile/Applications/9FB5D11F-42C0-42CA-A336-4B99FF97708F/example.app/example
0x2febf000 - 0x2fedffff  dyld armv7s  <4047d926f58e36b98da92ab7a93a8aaf> /usr/lib/dyld
...

В этом фрагменте журнал сбоев принадлежит двоичному образу приложения с именем example.app/example с UUID aa5e633efda8346cab92b01320043dc3.

Вы можете проверить UUID вашего двоичного пакета с помощью dwarfdump:

dwarfdump --uuid example.app/example
UUID: AA5E633E-FDA8-346C-AB92-B01320043DC3 (armv7) example.app/example

После этого вы должны проверить, принадлежат ли отладочные символы, которые у вас есть, этому двоичному файлу:

dwarfdump --uuid example.app.dSYM
UUID: AA5E633E-FDA8-346C-AB92-B01320043DC3 (armv7) example.app.dSYM/Contents/Resources/DWARF/example

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

Переходя к symbolicatecrashсценарию:

В Xcode 8.3 вы должны иметь возможность вызывать скрипт через

/Applications/Xcode.app/Contents/SharedFrameworks/DVTFoundation.framework/Versions/A/Resources/symbolicatecrash -v example.crash 2> symbolicate.log

Если его там нет, вы можете запустить его find . -name symbolicatecrashв каталоге Xcode.app, чтобы найти его.

Как вы можете видеть, здесь больше нет параметров. Таким образом, скрипт должен найти двоичное и отладочное символы вашего приложения, выполнив поиск в центре внимания. Он ищет символы отладки с определенным индексом com_apple_xcode_dsym_uuids. Вы можете сделать этот поиск самостоятельно:

mdfind 'com_apple_xcode_dsym_uuids = *'

соответственно

mdfind "com_apple_xcode_dsym_uuids == AA5E633E-FDA8-346C-AB92-B01320043DC3"

Первый вызов Spotlight дает вам все проиндексированные пакеты dSYM, а второй - .dSYMпакеты с определенным UUID. Если прожектор не найдет вашу .dSYMпосылку, то не symbolicatecrashбудет ни того, ни другого. Если вы делаете все это, например, в подпапке вашего ~/Desktopвнимания, вы сможете найти все.

Если найден symbolicatecrashваш .dSYMпакет, в строке должна быть следующая строка symbolicate.log:

@dsym_paths = ( <SOME_PATH>/example.app.dSYM/Contents/Resources/DWARF/example )

Для поиска вашей .appпосылки, поиск по центру вызывается следующим образом symbolicatecrash:

mdfind "kMDItemContentType == com.apple.application-bundle && (kMDItemAlternateNames == 'example.app' || kMDItemDisplayName == 'example' || kMDItemDisplayName == 'example.app')"

Если symbolicatecrashнаходит вашу .appпосылку, в ней должна быть следующая выписка symbolicate.log:

Number of symbols in <SOME_PATH>/example.app/example: 2209 + 19675 = 21884
Found executable <SOME_PATH>/example.app/example
-- MATCH

Если все эти ресурсы найдены, symbolicatecrashон должен распечатать символическую версию вашего журнала сбоев.

Если нет, вы можете передать свои файлы dSYM и .app напрямую.

symbolicatecrash -v --dsym <SOME_PATH>/<App_URI>.app.dSYM/<APP_NAME>.app.dsym <CRASHFILE> <SOME_OTHER_PATH>/<APP_NAME>.app/<APP_NAME> > symbolicate.log

Примечание: символьная обратная трассировка будет выводиться на терминал, а не symbolicate.log.

В последней версии Xcode (3.2.2) вы можете перетаскивать любые отчеты о сбоях в раздел «Журналы устройств» в Xcode Organizer, и они будут автоматически отображаться для вас. Я думаю, что это работает лучше всего, если вы создали эту версию приложения, используя Build & Archive (также часть Xcode 3.2.2)

Я сделал это успешно, используя следующие шаги.

Шаг 1. Создайте папку на рабочем столе, я назову ее «CrashReport» и добавлю в нее три файла («MYApp.app», «MyApp.app.dSYM», «MYApp_2013-07-18.crash»).

Шаг 2: Откройте Finder и перейдите в Приложения, где вы найдете приложение Xcode, щелкните по нему правой кнопкой мыши и нажмите «Показать содержимое пакета», после этого следуйте по этому простому пути. "Содержание-> Разработчик-> Платформы-> iPhoneOS.platform-> Разработчик-> Библиотека-> PrivateFrameworks- > DTDeviceKit.framework -> Версии- > A-> Ресурсы"

ИЛИ

"Содержание-> Разработчик-> Платформы-> iPhoneOS.platform-> Разработчик-> Библиотека-> PrivateFrameworks- > DTDeviceKitBase.framework -> Версии- > A-> Ресурсы"

ИЛИ

Для Xcode 6 и выше путь является Applications / Xcode.app / Contents / SharedFrameworks / DTDeviceKitBase.framework / Versions / A / Resources

Где вы найдете файл «symbolicatecrash», скопируйте его и вставьте в папку «CrashReport».

Шаг 3: запустить терминал, запустить эти 3 команды

1. cd / Users / mac38 / Desktop / CrashReport и нажмите кнопку Enter

2. export DEVELOPER_DIR = "/ Applications / Xcode.app / Contents / Developer" и нажмите Enter

3. ./symbolicatecrash -A -v MYApp_2013-07-18.crash MyApp.app.dSYM и нажмите Enter Now is Done .. (ПРИМЕЧАНИЕ: версии около 6.4 или более поздней версии не имеют опции -A - просто пропустите ее).

Шаги для автоматической символизации отчета о сбое с использованием XCode:

ОБНОВЛЕНО ДЛЯ XCODE 9

1. Подключите любое устройство iOS к вашему Mac (да, физическое, да, я знаю, что это глупо)

2. Выберите «Устройства» в меню «Окно».

3. Нажмите ваше устройство слева и ПРОСМОТРЕТЬ ЖУРНАЛЫ УСТРОЙСТВА справа

4. Подождите. Это может занять минуту, чтобы появиться. Может быть, Command-Aтогда Deleteэто ускорит это.

5. Критический недокументированный шаг: переименуйте отчет о сбое, полученный из iTunesConnect, из.txtрасширения в.crashрасширение

6. Перетащите отчет о сбое в эту область слева

И тогда Xcode будет символизировать отчет о сбое и отобразить результаты.

Источник: https://developer.apple.com/library/ios/technotes/tn2151/_index.html

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

Вот как я символизирую их с помощью atos, если это необходимо обратному следу:

1. В Xcode (4.2) перейдите к органайзеру, щелкните правой кнопкой мыши по архиву, из которого был сгенерирован файл .ipa.

2. В Терминале, перейдите в xcarchive, напримерMyCoolApp 10-27-11 1.30 PM.xcarchive

3. Введите следующее atos -arch armv7 -o 'MyCoolApp.app'/'MyCoolApp' (не забывайте одинарные кавычки)

4. Я не включаю свой символ в этот вызов. То, что вы получите, это блочный курсор на пустой строке.

5. Затем я копирую / вставляю свой код символа в курсор этого блока и нажимаю ввод. Вы увидите что-то вроде:

   -[MyCoolVC dealloc] (in MyCoolApp) (MyCoolVC.m:34)

6. Вы вернулись к курсору блока и можете вставить другие символы.

Возможность пройти через одну трассировку без повторного ввода первого бита - это хорошая экономия времени.

Наслаждайтесь!

Я также поместил dsym, комплект приложений и журнал сбоев в один каталог перед запуском символического сбоя

Затем я использую эту функцию, определенную в моем .profile, чтобы упростить запуск symbolicatecrash:

function desym
{
    /Developer/Platforms/iPhoneOS.platform/Developer/Library/PrivateFrameworks/DTDeviceKit.framework/Versions/A/Resources/symbolicatecrash -A -v $1 | more
}

Добавленные аргументы могут вам помочь.

Вы можете убедиться, что прожектор «видит» ваши файлы dysm, выполнив команду:

mdfind 'com_apple_xcode_dsym_uuids = *'

Ищите dsym, который есть в вашем каталоге.

ПРИМЕЧАНИЕ. Начиная с последней версии Xcode, каталог разработчика больше не существует. Вы можете найти эту утилиту здесь:

/Applications/Xcode.app/Contents/SharedFrameworks/DTDeviceKitBase.framework/Vers ионы / А / Ресурсы / symbolicatecrash

Просто и обновленный ответ для xcode 6.1.1.

ШАГОВ

1.Xcode> Window> Устройства.

2.Выберите устройство из списка устройств в разделе УСТРОЙСТВА.

3. Выберите Просмотр журналов устройства.

4.В разделе «Все журналы» вы можете перетащить файл drop.crash.

5.Xcode автоматически символизирует отчет о сбое для вас.

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

Несмотря на то, что я разрабатывал приложения уже несколько лет, я впервые отлаживал бинарный файл, и я чувствовал себя как полный NOOB, выясняющий, где все файлы, т.е. где находятся * .app * .dSYM и журналы сбоев? Мне пришлось читать несколько постов, чтобы понять это. Изображение стоит тысячи слов, и я надеюсь, что этот пост поможет кому-нибудь еще в будущем.

1- Сначала зайдите на itunesconnect и загрузите журналы сбоев. ПРИМЕЧАНИЕ. В большинстве случаев вы можете получить что-то вроде «Слишком мало отчетов отправлено для отображения». По сути, недостаточно пользователей отправили отчеты о сбоях в Apple, и в этом случае вы ничего не можете сделать в этот момент.

2. Теперь, если вы не изменили свой код с момента отправки двоичного кода в Apple, запустите Xcode для этого проекта и снова выполните Product -> Archive. В противном случае просто найдите ваш последний представленный двоичный файл и щелкните по нему правой кнопкой мыши.

В Xcode 4.2.1 откройте Организатор , затем перейдите к журналам библиотеки / устройства и перетащите ваш файл .crash в список журналов аварий. Это будет символизировано для вас через несколько секунд.

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

Используя Xcode 4, задача еще проще:

• открыть Организатор ,
• нажмите на библиотеку | Журнал устройства в левой колонке
• нажмите кнопку « Импорт » в нижней части экрана ...

и вуаля. Файл журнала импортируется и символизируется автоматически для вас. При условии, что вы сначала заархивировали сборку, используя Xcode -> Product -> Archive .

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

Я попытался использовать командную строку, поместив отчет о сбое в ту же папку, что и файл .app (который я отправил в хранилище) и файл .dSYM:

$ symbolicatecrash "My App_date_blahblah-iPhone.crash" "My App.app"

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

В моем случае я перетаскивал отчеты о сбоях прямо из Почты в Организатор. По какой-то причине это не позволило символизировать сообщения о сбоях (хотелось бы знать, почему).

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

Я знаю очень конкретный случай. Но думал, что поделюсь на всякий случай.

Вот еще одна проблема, которую я имею с symbolicatecrash - она ​​не будет работать с приложениями, в которых есть пробелы (например, «Test App.app»). Примечание. Я не думаю, что вы можете указывать пробелы в их имени при отправке, поэтому вы должны их все равно удалить, но если у вас уже есть сбои, требующие анализа, исправьте symbolicatecrash (4.3 GM) следующим образом:

240c240
<         my $cmd = "mdfind \"kMDItemContentType == com.apple.application-bundle && kMDItemFSName == $exec_name.app\"";
---
>         my $cmd = "mdfind \"kMDItemContentType == com.apple.application-bundle && kMDItemFSName == '$exec_name.app'\"";
251c251
<             my $cmd = "find \"$archive_path/Products\" -name $exec_name.app";
---
>             my $cmd = "find \"$archive_path/Products\" -name \"$exec_name.app\"";

Для тех, кто использует Airbrake, есть солидный ответ выше, но он не будет работать для меня без настройки:

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

• Создать новый каталог на рабочем столе или где-либо еще
• Найти нужный архив в органайзере XCode
• Дважды нажмите, чтобы показать в поиске
• Дважды нажмите, чтобы показать содержимое пакета
• Скопируйте файл .dSYM и файл .app в новый каталог
• CD в ​​новый каталог
• Запустите эту команду: atos -arch armv7 -o 'Vimeo.app' / 'Vimeo'
• Терминал войдет в интерактивный ход
• Вставьте адрес памяти и нажмите Enter, он выведет имя метода и номер строки
• Или введите следующую команду: atos -arch armv7 -o 'Vimeo.app' / 'Vimeo' Чтобы получить информацию только по одному адресу

Комбинация, которая работала для меня, была:

1. Скопируйте файл dSYM в каталог, где был отчет о сбое
2. Разархивируйте файл ipa, содержащий приложение ('unzip MyApp.ipa')
3. Скопируйте двоичный файл приложения из полученной разнесенной полезной нагрузки в ту же папку, что и отчет о сбое и файл символов (что-то вроде «MyApp.app/MyApp»).
4. Импортируйте или повторно символизируйте отчет о сбое из органайзера XCode

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

Мне пришлось много взломать скрипт symbolicatecrash, чтобы он работал правильно.

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

Вы должны сделать копию вашего symbolicatecrash, прежде чем пытаться использовать эти патчи, которые заставят его выглядеть в dsym:

Вокруг строки 212 в функции getSymbolPathFor_dsymUuid

212     my @executablePath = grep { -e && ! -d } glob("$dsymdir" . "/Contents/Resources/DWARF/" . $executable);

Вокруг строки 265 в функции matchUUID

265             return 1;

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

• скопируйте файлы .app, crash_report и DSYM в папку.
• подключите устройство с помощью xcode
• Затем перейдите в окно -> выбрать устройства -> просмотреть журналы устройства
• Затем выберите это устройство, удалите все журналы.
• перетащите ваш сбой в разделе журнала устройства. это будет автоматически символизировать аварию. просто щелкните правой кнопкой мыши на отчете и экспортируйте его.

Удачного кодирования,
Рияз

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

Предпосылками

Создайте папку и положите туда 4 вещи:

1. symbolicatecrash Perl-скрипт - есть много SO-ответов, которые говорят о его местонахождении

2. Архив сборки, которая соответствует сбоям (из Xcode Organizer. Просто как Show in Finderи скопируйте) [я не уверен, что это необходимо]

3. Все xccrashpointпакеты - (из Xcode Organizer. Show in FinderВы можете скопировать все пакеты в каталоге или одну точку xccrash, которую вы хотели бы обозначить символом)

4. Добавьте этот короткий скрипт в каталог:

   #!/bin/sh
   
   echo "cleaning old crashes from directory"
   rm -P *.crash
   rm -P *.xccrashpoint
   rm -r allCrashes
   echo "removed!"
   echo ""
   echo "--- START ---"
   echo ""
   
   mkdir allCrashes
   mkdir symboledCrashes
   find `ls -d *.xccrashpoint` -name "*.crash" -print -exec cp {} allCrashes/ \;
   
   cd allCrashes
   for crash in *.crash; do
       ../symbolicatecrash $crash > ../symboledCrashes/V$crash
   done
   cd ..
   
   echo ""
   echo "--- DONE ---"
   echo ""

Сценарий

Когда вы запустите скрипт, вы получите 2 каталога.

1. allCrashes- все сбои от всех xccrashpointбудут там.

2. symboledCrashes - тот же сбой, но теперь со всеми символами.

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

Я обнаружил, что большинство предложенных альтернатив не работает в последней версии XCode (протестировано с Xcode 10). Например, мне не повезло перетаскивание журналов .crash в Xcode -> Organizer -> Журналы устройств - просмотр.

Я рекомендую использовать инструмент Symbolicator https://github.com/agentsim/Symbolicator

• Git clone хранилище Symbolicator и скомпилируйте и запустите с Xcode
• Скопируйте файл .crash (файл ascii, с трассировкой стека в начале файла) и .xarchive аварийного выпуска в ту же временную папку
• Перетащите файл .crash на значок Symbolicator в Dock.
• Через 5-30 секунд символический файл сбоя создается в той же папке, что и .crash и .xarchive

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

Я немного рассердился из-за того факта, что здесь ничего не «просто работает», поэтому я провел некоторое расследование, и в результате получилось следующее:

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

Исправление: загрузка отчетов о сбоях с сервера онлайн. Они называются «сбой» и по умолчанию идут в папку ~ / Downloads /. Имея это в виду, этот сценарий будет "делать правильные вещи", а отчеты о сбоях будут отправляться в Xcode (органайзер, журналы устройств) и символизация будет выполнена.

Сценарий:

#!/bin/bash
# Copy crash reports so that they appear in device logs in Organizer in Xcode

if [ ! -e ~/Downloads/crash ]; then 
   echo "Download a crash report and save it as $HOME/Downloads/crash before running this script."
   exit 1
fi

cd ~/Library/Logs/CrashReporter/MobileDevice/
mkdir -p actx # add crash report to xcode abbreviated
cd actx

datestr=`date "+%Y-%m-%d-%H%M%S"`

mv ~/Downloads/crash "actx-app_"$datestr"_actx.crash"

Вещи могут быть автоматизированы, куда вы можете перетащить в Xcode Organizer, выполнив две вещи, если вы используете QuincyKit / PLCR.

Во-первых, вам нужно отредактировать удаленный скрипт admin / actionapi.php ~ строка 202. Похоже, что метка времени неверна, поэтому файл заканчивается именем «crash», которое Xcode не распознает (ему нужно что-то точка аварии):

header('Content-Disposition: attachment; filename="crash'.$timestamp.'.crash"');

Во-вторых, на стороне iOS в QuincyKit BWCrashReportTextFormatter.m ~ строка 176, измените @"[TODO]"на, @"TODO"чтобы обойти плохих персонажей.

atos устарела, поэтому, если вы работаете с OSX 10.9 или более поздней версии, вам может потребоваться запустить

xcrun atos

Предупреждение: / usr / bin / atos движется и будет удален из будущего выпуска OS X. Это теперь доступно в инструментах разработчика Xcode, чтобы быть вызванным через:xcrun atos

Мне нравится использовать Textwrangler, чтобы точно определить ошибки в исходной загрузке приложения. (Данные о сбое будут найдены в вашей учетной записи itunesConnect.) Используя описанный выше метод Sachin, я копирую original.crash в TextWrangler, а затем копирую созданный мной файл symbolicatecrash в другой файл TextWrangler. Сравнивая два файла, выявляем различия. Файл symbolicatecrash будет иметь различия, которые указывают на файл и номер строки проблем.

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

Ссылки на документы: https://docs.fabric.io/apple/crashlytics/missing-dsyms.html#missing-dsyms

Все о пропавших без вести dSYMs Fabric включает в себя инструмент для автоматической загрузки dSYM вашего проекта. Инструмент запускается через скрипт / run, который добавляется в фазу сборки Run Script во время процесса адаптации. Однако могут быть определенные ситуации, когда загрузка dSYM не удалась из-за уникальных конфигураций проекта или если вы используете битовый код в своем приложении. Если загрузка не удалась, Crashlytics не может символизировать и отображать сбои, и на панели управления Fabric появится предупреждение «Missing dSYM».

Отсутствующие dSYM могут быть загружены вручную, следуя шагам, описанным ниже.

Примечание. В качестве альтернативы автоматизированному инструменту загрузки dSYM Fabric предоставляет инструмент командной строки (символы загрузки), который можно настроить вручную для запуска в процессе сборки проекта. См. Раздел загрузки символов ниже для инструкций по конфигурации.

...