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

Я ищу, чтобы попытаться описать отчеты о сбоях iPhone в iPhone.

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

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

Что теперь?

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

symbolicatecrash crashreport.crash myApp.app.dSYM

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

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

+424
22 сент. '09 в 15:44
источник поделиться
25 ответов

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

  • Скопируйте освобожденный файл .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.

Примечание

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

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

+687
10 февр. '11 в 8:44
источник

Связанные вопросы


Похожие вопросы

После прочтения всех этих ответов здесь, чтобы символизировать журнал сбоев (и, наконец, преуспевающий), я думаю, что здесь есть некоторые моменты, которые действительно важны для того, чтобы определить, почему вызов символьного 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.

+165
02 дек. '12 в 12:47
источник

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

+114
20 апр. '10 в 6:33
источник

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

Шаг 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 - просто оставьте ее).
+72
19 июл. '13 в 13:50
источник

Я использую 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 один элемент без повторного входа в первый бит - приятная экономия времени.

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

+28
27 окт. '11 в 21:06
источник

Я также добавляю 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

+28
22 сент. '09 в 21:18
источник

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

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

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

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

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

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

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

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

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

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

+25
23 июн. '16 в 3:54
источник

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

ШАГОВ

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

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

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

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

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

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

+20
02 февр. '15 в 14:45
источник

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

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

enter image description here

enter image description here

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

enter image description here

enter image description here

enter image description here

enter image description here

+14
06 июл. '14 в 19:13
источник

В XCode 4.2.1 откройте "Органайзер", затем перейдите в "Журнал библиотек/устройств" и перетащите свой .crash файл в список журналов сбоев. Он будет отображаться для вас через несколько секунд. Обратите внимание, что вы должны использовать тот же экземпляр XCode, в который была заархивирована исходная сборка (т.е. Архив для вашей сборки должен существовать в Organizer).

+8
27 янв. '12 в 17:52
источник

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

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

и вуаля. Файл журнала импортируется и автоматически символизируется для вас. Если вы архивируете сборку с помощью XCode → Продукт → Архив первым

+8
14 июн. '11 в 18:21
источник

Устроитель Magical XCode не настолько волшебный, чтобы символизировать мое приложение. У меня нет никаких символов для отчетов о сбоях, которые я получил от Apple из-за неудачной заявки на приложение.

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

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

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

+7
12 окт. '10 в 15:06
источник

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

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

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

+6
05 апр. '11 в 3:10
источник

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

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

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

Вот еще одна проблема, с которой я сталкиваюсь с символикой 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\"";
+4
07 мар. '11 в 13:02
источник

Сочетание, которое сработало для меня, было:

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

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

+4
02 нояб. '12 в 15:50
источник

Мне пришлось сделать много взлома символа 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;
+3
26 янв. '10 в 19:43
источник

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

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

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

+1
15 февр. '17 в 6:24
источник

Я предпочитаю 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. он автоматически очистится. удачи!

+1
07 мая '17 в 6:02
источник

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

0
09 июн. '16 в 23:28
источник

Я обнаружил, что большинство предложенных альтернатив не работает в последней версии 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
0
20 нояб. '18 в 10:31
источник

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

xcrun atos

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

0
25 нояб. '13 в 23:45
источник

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

0
22 сент. '09 в 20:51
источник

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

Настройка: 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", чтобы обойти плохие символы.

0
09 янв. '13 в 16:50
источник

Мы используем 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 предоставляет инструмент командной строки (символы загрузки), который можно настроить вручную для выполнения как часть процесса сборки ваших проектов. См. Раздел "Загрузка-символы" ниже для инструкций по настройке.

...

-1
05 янв. '18 в 5:42
источник

Посмотрите другие вопросы по меткам или Задайте вопрос