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

Ответ 1

Шаги по анализу отчета о сбоях из яблока:

• Скопируйте освобожденный файл .app, который был перенесен в appstore, файл .dSYM, созданный на момент выпуска, и отчет о сбое получают из APPLE в папку FOLDER.

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

• Запустите atos -arch armv7 -o APPNAME.app/APPNAME MEMORY_LOCATION_OF_CRASH. Место расположения памяти должно быть тем местом, в котором приложение разбилось как на отчет.

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

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

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

Символизирующий IPA

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

Примечание

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

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

Ответ 2

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

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

• Сам файл журнала сбоев (т.е. example.crash), либо экспортирован из организатора XCode, либо получен из iTunes Connect.
• Пакет .app (т.е. example.app), который сам содержит бинарное приложение, принадлежащее журналу сбоев. Если у вас есть пакет .ipa (т.е. example.ipa), вы можете извлечь пакет .app, распакуя пакет .ipa (т.е. unzip example.ipa). После этого пакет .app находится в извлеченной папке Payload/.
• Пакет .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 script:

В Xcode 8.3 вы можете вызвать script через

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

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

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

mdfind 'com_apple_xcode_dsym_uuids = *'

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

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

В первом вызове прожектора вы получаете все индексированные пакеты 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.

Ответ 3

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

Ответ 4

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

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

Шаг 2: Откройте Finder и перейдите в Приложения, где вы найдете приложение Xcode, щелкните по нему правой кнопкой мыши и нажмите "Показать содержимое пакета", после чего следуйте по этому простому пути. "Contents-> Разработчик → Platforms-> iPhoneOS. platform-> Разработчик → Library-> PrivateFrameworks-> DTDeviceKit.framework → Versions-> A-> Resources"

ИЛИ ЖЕ

"Contents-> Разработчик → Platforms-> iPhoneOS. platform-> Разработчик → Library-> PrivateFrameworks-> DTDeviceKitBase.framework → Versions-> A-> Resources"

ИЛИ ЖЕ

Для 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 - просто оставьте ее).

Ответ 5

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

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

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

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

3. Нажмите на свое устройство слева и VIEW DEVICE LOGS справа

4. Подождите. Это может занять минутку. Возможно, Command-A затем Delete ускорит это.

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

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

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

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

Ответ 6

Я также добавляю dsym, app bundle и crash log вместе в том же каталоге перед запуском символьного сбоя

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

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

Ответ 7

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

Вот как я их символизирую с atos, если ему нужна backtrace:

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

• В терминале, cd в xcarchive, например MyCoolApp 10-27-11 1.30 PM.xcarchive

• Введите atos -arch armv7 -o 'MyCoolApp.app'/'MyCoolApp' (не забудьте одинарные кавычки)

• Я не включаю свой символ в этот вызов. Вы получаете блок-курсор на пустой строке.

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

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

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

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

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

Ответ 8

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

ШАГОВ

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

2.Выберите устройство из списка устройств в разделе DEVICES.

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

4. В разделе "Все журналы" вы можете напрямую перетащить отчет report.crash

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

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

Ответ 9

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

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

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

Ответ 10

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

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

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

Ответ 11

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

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

Ответ 12

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

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

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

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

Ответ 13

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

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

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

Ответ 14

Вот еще одна проблема, с которой я сталкиваюсь с символикой crash - она ​​не будет работать с приложениями, в которых есть пробелы в своем пакете (т.е. "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\"";

Ответ 15

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

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

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

Ответ 16

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

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

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

Ответ 17

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

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

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

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

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

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

265             return 1;

Ответ 18

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

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

счастливое кодирование,
Риаз

Ответ 19

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

Предпосылки

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

• symbolicatecrash perl script - есть много ответов SO, в которых указывается местоположение

• Архив сборки, соответствующий авариям (из Xcode Organizer. simple as Show in Finder и copy) [Я не уверен, что это необходимо]

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

• Добавьте этот короткий script в каталог:

  #!/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 ""
  

Script

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

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

• symboledCrashes - те же ошибки, но теперь со всеми символами.

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

Ответ 20

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

Ответ 21

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

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

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

script:

#!/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.

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

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

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

Ответ 22

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

xcrun atos

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

Ответ 23

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

Ответ 24

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

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

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

Ответ 25

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

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

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

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

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

...