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

433

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

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

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

Что теперь?

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

symbolicatecrash crashreport.crash myApp.app.dSYM

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

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

Jasarien
источник
3
Вы также можете увидеть мой ответ на iPhone SDK: Где находится symbolicatecrash.sh? , Я перечисляю, где найти symbolicatecrashкоманду, как ее использовать и как найти файл dSYM, необходимый для символизации.
Сэм
6
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/Library/PrivateFrameworks/DTDeviceKit.framework/Versions/A/Resources/symbolicatecrash
logancautrell,
5
Я создал скрипт , который может помочь: github.com/amleszk/scripts/blob/master/...
amleszk
1
Если кому-то интересно, где можно взять * .app, * .dSYM и журналы сбоев, посмотрите на мой ответ ниже.
Сэм Б
3
Вы можете сослаться на это: medium.com/@Mrugraj/crash-re-symbolication-5c28d3a3a883
Mrug

Ответы:

689

Шаги для анализа отчета о сбое от 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.

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

Навин Шан
источник
12
Просто подсказка к ответу @NaveenShan, пример из реальной жизни сделает это, atos -o myApp.app/Contents/MacOS/myApp 0x0000000100001f2c и вы получите -[HUDWindow sizedHUDBackground] (in myApp) + 1197
loretoparisi
3
Какой адрес вы используете? Журналы имеют две колонки адресов после каждой функции, а вторая имеет + и смещение некоторого вида. Как 0x332da010 0x332d9000 + 4112.
Оскар
7
@OscarGoldman Второй адрес, например: - В 0x332da010 0x332d9000 + 4112. Используйте 0x332d9000.
Навин Шан
4
Кроме того, если используется без адреса, он позволяет анализировать несколько местоположений, отправляя их по одному.
Пол Арделеану
42
С этим ответом связано несколько проблем: 1. Это может работать только в том случае, если в двоичном файле приложения нет разделенных символов. И сборки выпуска по умолчанию имеют их. 2. Даже если символы доступны, он никогда не покажет номер строки. Только символизация с dSYM обеспечит это. 3. Вы не можете просто использовать адрес памяти, показанный в трассировке стека, адрес должен быть нормализован относительно начального адреса памяти, в который загружено приложение. Подробнее см. Этот ответ: stackoverflow.com/questions/13574933/…
Керни
173

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

Андреас Клёбер
источник
я могу найти все файлы, однако я получаю это, и никаких символических выходных данныхNo crash report version in testlog.crash at /usr/bin/symbolicatecrash line 921.
Джере
1
Это было действительно полезно! В моем случае файл .app имеет другое имя, чем имя исполняемого файла (я не знаю почему, но он построен таким образом Xcode). После переименования файла .app в архиве XCode символика сработала.
Хриссан
29
Это отличное объяснение и должно быть главным ответом ИМО, спасибо. Обратите внимание , что вы , возможно , придется установить DEVELOPER_DIRпеременную окружения , если скрипт жалуется на это нравится так: export DEVELOPER_DIR=`xcode-select --print-path` . Я добавил эту строку в мой ~/.bash_profile. См. Stackoverflow.com/q/11682789/350761
Элиот
1
Обратите внимание , что для Xcode 5, это переехал: <PATH_TO_Xcode.app> /Contents/Developer/Platforms/iPhoneOS.platform/Developer/Library/PrivateFrameworks/DTDeviceKitBase.framework/Versions/Current/Resources/symbolicatecrash
Элиот
1
Символическое падение также имеет несколько полезных опций. <SYMBOL_PATH> Additional search paths in which to search for symbol rich binaries -o | --output <OUTPUT_FILE> The symbolicated log will be written to OUTPUT_FILE. Defaults to "-" (i.e. stdout) if not specified -d | --dsym <DSYM_BUNDLE> Adds additional dSYM that will be consulted if and when a binary's UUID matches (may be specified more than once)
benuuu
115

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

Алан Роджерс
источник
3
Это просто не работает с Xcode4, при новой установке. Кажется, это новый баг :(
Адам,
1
Я не уверен, что это решит ту же проблему, что и у вас, но кто-то пропатчил символьный скрипт github.com/nskboy/symbolicatecrash-fix YMMV :)
Алан Роджерс
2
Этот совет работает с Xcode 4.2. Поместите аварийные журналы в журналы устройств Организатора. Перезапустите Организатор и получите символические журналы аварий !!! Спасибо.
harshit2811
2
Это не сработало у меня, когда я импортировал файл архива с другого компьютера, чтобы получить журнал сбоев. :( По этой причине мне пришлось вручную символизировать файл. Вы можете найти шаги о том, как сделать символику здесь: iPhone SDK: Где находится symbolicatecrash.sh?
Сэм,
3
Не работайте со мной с загруженными отчетами о сбоях из iTunes Connect.
Дмитрий
72

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

Шаг 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 - просто пропустите ее).
SachinVsSachin
источник
3
для DTServiceKit смотрите в Applications / Xcode.app / Contents / SharedFrameworks
Райан Хейтнер
3
Спасибо. По состоянию на 9 апреля 2015 года это то, что у меня сработало без нареканий. Одна вещь, это то, что я получил Unknown option: Aза symbolicatecrash, но процесс все равно запустился
Matt Fiocca
1
Я хотел бы дать тысячу баллов за этот ответ. В этой теме так много практических рекомендаций ... но это тот, который работает на самом низком уровне, поэтому он ВСЕГДА работает. Задняя боль - это удар по всем ступеням, но когда все остальное терпит неудачу, это делает работу.
Чад Робинсон
35

Шаги для автоматической символизации отчета о сбое с использованием 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

Уильям Энтрикен
источник
1
Это официальная процедура Apple. Должен быть ответ.
Джамми
2
Спасибо, сейчас добавляю картинки. Также включен SUPER UNDOCUMENTED шаг. Я думал о том, чтобы сделать немного текста и добавить его туда, чтобы он действительно выделялся. Тогда я перестал думать об этом.
Уильям Энтрикен
1
Спасибо! Ни один из других ответов на самом деле не говорит о том, что используемое устройство не обязательно должно быть устройством (или даже типом устройства), на котором произошел сбой.
галактикух
Быстрое примечание, потому что для меня это не будет повторно символизировать. Мне также пришлось открыть органайзер, щелкнуть по сборке в архиве, нажать «Загрузить символы отладки». Тогда я мог бы повторно символизировать в представлении журнала устройства. Это было для аварийного журнала, загруженного из Apple после отклоненного обзора.
gregthegeek
28

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

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

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

averydev
источник
28

Я также поместил 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

Кендалл Хельмштеттер Гелнер
источник
1
Я посмотрел на вывод mdfind, и файл dSYM определенно можно увидеть в центре внимания. Однако скрипт symbolicatecrash по-прежнему не выводит ничего, отличного от самого отчета о сбое. Даже используя аргументы, которые вы предоставили.
Jasarien
Сценарий должен выдавать некоторый текст предупреждения в начале, если он не может найти dsym - можете ли вы найти это и посмотреть, что он говорит?
Кендалл Хельмштеттер Гелнер
Также попробуйте добавить "." после команды это будет «symbolicatecrash -A -v MyApp.crashlog». , Это заставляет его искать в текущем каталоге, если он этого еще не делает.
Кендалл Хельмштеттер Гелнер
Значение «Can't exec» / usr / bin / xcode-select »: нет такого файла или каталога в /Developer/Platforms/iPhoneOS.platform/Developer/Library/Xcode/Plug-ins/iPhoneRemoteDevice.xcodeplugin/Contents/Resources/ символическая строка 49. "
Бапа
К сожалению, по- видимому , есть другой SO вопрос для этого stackoverflow.com/questions/1859852/...
bpapa
21

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

ШАГОВ

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

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

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

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

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

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

Адитья Аггарвал
источник
3
Отчеты о сбоях, которые я скачал из Apple Resolution Center, обычно имеют расширение .txt. Не забудьте переименовать их в .crash, в противном случае журналы устройств могут отказаться добавлять их. Хорошо работать для моего текущего XCode 6.3.1
Тони
3
Это официальная процедура Apple. Должен быть ответ. Ссылка Apple: Техническое примечание TN2151: Понимание и анализ отчетов о
сбоях
Как мы это сделаем, если сбой произошел от Apple / iTunesConnect? То есть, другими словами, мы на самом деле не знаем или не имеем устройства, на котором произошел сбой?
галактикух
14

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

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

введите описание изображения здесь

введите описание изображения здесь

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

введите описание изображения здесь

введите описание изображения здесь

введите описание изображения здесь

введите описание изображения здесь

Сэм Б
источник
8

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

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

cberkley
источник
8

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

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

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

Себастьян Стормак
источник
1
Как ни странно, импорт не имеет никакого эффекта. Поместить .app, .dSYM и .crash, а затем запустить symbolicatecrash в файле .crash (без каких-либо дополнительных аргументов) работало (XCode 4)
русский язык,
7

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

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

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

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

Andrews
источник
Для основного Foundation dSYM (может быть, китаец) парень загрузил dSYM на свой общий диск Google, просто загрузите его и добавьте в папку «устройства поддерживаются», и это будет решено. github.com/Zuikyo/iOS-System-Symbols
Харунага
6

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

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

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

samvermette
источник
Я предполагаю, что это может быть как-то связано с прожектором. Есть ли вероятность, что место, где организатор хранит ваши журналы, не было проиндексировано в центре внимания?
Jasarien
4

Вот еще одна проблема, которую я имею с 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\"";
Аластер Стюарт
источник
Что бы это ни стоило, я заполнил этот вопрос, и он исправлен в [отредактировано]
Аластер Стюарт,
4

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

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

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

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

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

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

Шон Айткен
источник
3

Мне пришлось много взломать скрипт 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;
JerryH
источник
1

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

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

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

Шайк Рияз
источник
Лучшие короткие и сладкие ответы, следуйте каждому шагу, написанному в этом ответе. developer.apple.com/library/content/technotes/tn2151/… перейдите по этой ссылке, чтобы найти разницу между несимволизированным и полностью символизированным.
Нинад Камбли
1

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

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

Создайте папку и положите туда 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. Вам не нужно очищать каталог от старых сбоев перед запуском скрипта. это очистит автоматически. удачи!

Ицхака
источник
1

Я обнаружил, что большинство предложенных альтернатив не работает в последней версии 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
Эркки Ноксо-Койвисто
источник
0

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

rpetrich
источник
Если вы прочитали вопрос, я заявил, что сохранил исходный файл dSYM, который был сгенерирован одновременно с отправкой двоичного файла.
Jasarien
0

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

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

Kalle
источник
0

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

xcrun atos

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


источник
Кажется, Apple разрешает формату DWARF изменяться с каждым выпуском инструментов (имеет смысл, особенно с появлением Swift), поэтому они переносят его в дистрибутив инструмента.
Дэвид Гиш
0

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

Горный человек
источник
-2

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

...

Тим
источник