Обозначение отчетов о сбоях приложений iPhone

StackOverflow https://stackoverflow.com/questions/1460892

  •  13-09-2019
  •  | 
  •  

Вопрос

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

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

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

Что теперь?

Я попробовал вызвать:

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 для обозначения — просто переименуйте расширение .ipa в .zip, извлеките его, и мы сможем получить папку полезной нагрузки, содержащую приложение.В этом случае нам не нужен файл .dSYM.

Примечание

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

Подробнее см. здесь почта

Другие советы

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

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

  1. Сам файл журнала сбоев (т. е. example.crash), либо экспортированный из XCode organizer, либо полученный из 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

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

Переходя к 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, чтобы найти его.

Как вы можете видеть, больше никаких параметров не задано.Таким образом, скрипт должен найти двоичные файлы вашего приложения и отладить символы, запустив поиск spotlight.Он выполняет поиск отладочных символов по определенному индексу, называемому 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.Если spotlight не находит ваш .dSYM затем упакуйте symbolicatecrash не будет ни того, ни другого.Если вы делаете все эти вещи, напримерво вложенной папке вашего ~/Desktop прожектор должен уметь находить все.

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

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

За то, что нашел свой .app пакет поиска spotlight, подобный следующему, вызывается 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, и они автоматически будут отображаться для вас символами.Я думаю, это работает лучше всего, если вы создали эту версию приложения с помощью Build & Archive (также часть Xcode 3.2.2).

Я сделал это успешно, выполнив следующие шаги.

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

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

ИЛИ

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

ИЛИ

Для Xcode 6 и выше пути IS Applications/xcode.app/contents/sharedframeworks/dtdevicekitbase.framework/versions/a/resources

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

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

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

  2. экспортируйте DEVELOPER_DIR="/Applications/Xcode.app/Contents/Developer" и нажмите Enter.

  3. ./symbolicatecrash -A -v MYApp_2013-07-18.crash MyApp.app.dSYM и нажмите Enter. Теперь все готово..(ПРИМЕЧАНИЕ:версии около 6.4 или новее не имеют опции -A — просто оставьте ее).

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

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

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

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

  3. Нажмите на свое устройство слева и ПРОСМОТР ЖУРНАЛОВ УСТРОЙСТВА справа.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

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

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

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

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

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

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

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

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

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

Вы можете проверить, «видит» ли Spotlight ваши файлы Dym, выполнив команду:

mdfind 'com_apple_xcode_dsym_uuids = *'

Найдите dsym, который у вас есть в вашем каталоге.

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

/Applications/Xcode.app/Contents/SharedFrameworks/DTDeviceKitBase.framework/Vers‌​ions/A/Resources/symbolicatecrash

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

ШАГИ

1.Xcode>Окно>Устройства.

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

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

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

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

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

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

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

enter image description here

enter image description here

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

enter image description here

enter image description here

enter image description here

enter image description here

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

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

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

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

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

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

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

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

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

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

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

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

Вот еще одна проблема, с которой я столкнулся при использовании символического краша: он не работает с приложениями, в пакете которых есть пробелы (т. е.«Проверить App.app»).Примечание. Я не думаю, что вы можете иметь пробелы в их именах при отправке, поэтому вам все равно следует удалить их, но если у вас уже есть сбои, которые необходимо проанализировать, пропатчите символикатекреш (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 organizer
  • Дважды нажмите, чтобы открыть в finder
  • Дважды коснитесь, чтобы отобразить содержимое пакета
  • Скопируйте файл .dSYM и файл .app в новый каталог
  • компакт-диск в новом издании
  • Запустите эту команду: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.

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

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

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

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

  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. НЕ НУЖНО чистить каталог от старых сбоев перед запуском скрипта.он очистится автоматически.удачи!

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

Меня немного разозлил тот факт, что ничто здесь не «просто работает», поэтому я провел небольшое расследование и получил такой результат:

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

Исправление:загружать отчеты о сбоях с сервера онлайн.Они называются «crash» и по умолчанию попадают в папку ~/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.) Используя описанный выше метод Сачина, я копирую original.crash в TextWrangler, затем копирую созданный мной файл символикатекреш в другой файл TextWrangler.Сравнение двух файлов позволяет выявить различия.Файл символики-кэша будет иметь различия, которые указывают на проблемы с файлом и номером строки.

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

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

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

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

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

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

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

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

...

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top