Xcode - несоответствие UUID с каркасом dSYMs

Question

У меня есть проект Xcode для настольных ПК OSX, который включает в себя другой проект Xcode (фреймворк) в качестве зависимости. Когда я создаю архив приложения, он генерирует два пакета dSYM - один для приложения и один для фреймворка.

Когда я символизирую аварии, полученные из приложения, символы из пакета приложений отображаются правильно (с именами файлов и номерами строк). Однако символы из фреймворка вообще не символизируют - они просто отображают имя и адрес структуры. Есть ли способ символизировать части трассировки стека с использованием кода рамки?

Глядя на архив, который я создал the.app пакет из, UUID из фреймворка dSYM не соответствует тому, который получает копируется в папку «Frameworks» в .app:

HCCommon рамочное внутри пакета .app в архивном файле:

/path/to/HipChat.xcarchive $ dwarfdump --uuid Products/Applications/HipChat.app/Contents/Frameworks/HCCommon.framework/HCCommon 
UUID: 84891A9C-19DB-3E16-BE7E-9D4056FFFB97 (x86_64) Products/Applications/HipChat.app/Contents/Frameworks/HCCommon.framework/HCCommon 

В.С. dSYM рамок HCCommon (в каталоге dSYMs в архивном файле):

/path/to/HipChat.xcarchive $ dwarfdump --uuid dSYMs/HCCommon.framework.dSYM/Contents/Resources/DWARF/HCCommon 
UUID: 767F2D97-9E0B-3C4D-8337-FDF5A9CA2D81 (x86_64) dSYMs/HCCommon.framework.dSYM/Contents/Resources/DWARF/HCCommon 

Answer 1

Я п Конечно, почему ваша сборка приводит к непоследовательным UUIDs dSYM. Когда мы делаем такие сборки (с некоторыми проверенными сейчас пятнами), у нас есть последовательные UUID.

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

Я нашел следующий, чтобы работать хорошо, если у вас есть, чтобы заставить конкретную dsym:

atos -arch x86_64 -o <path_to_dsym_within_package> -l <offset_of_framework> 

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

<path_to_dsym_within_package> относится к foo.framework.dSYM/Contents/Resources/DWARF/foo с последующим вашим бинарным именем, где foo этим имя рамки. Для нас это работает и для любого плагина.

<offset_of_framework> от смещения столбца в журнале аварии, где:

0 libsystem_kernel.dylib 0x7fff8e785ce2 0x7fff8e76f000 + 93410 
1 libsystem_c.dylib 0x7fff871afa7a 0x7fff8716e000 + 268922 
2 CTUtils 0x104e26c62 0x104e17000 + 64610 

В этом случае первый шестнадцатеричное число является адресом, второе шестнадцатеричное число это начальное смещение для конкретной структуры и значение + является десятичным смещением в рамках.

Вам понадобится второе число (шестнадцатеричное смещение) для командной строки выше, а первое число - конкретная строка/номер строки.

В худшем случае, там всегда используя dwarfdump непосредственно, с помощью:

dwarfdump <path_to_dSYM> --arch x86_64 --lookup <offset> 

<path_to_dSYM> путь к верхнему уровню папки «.dSYM» (в отличие от atos команды выше), и <offset> это смещение внутри модуля, что не так удобно, как atos.

P.S.atos должен быть установлен в /usr/bin/atos, если у вас установлены инструменты dev.

Answer 2

Я тоже столкнулся с этой проблемой. После некоторого расследования выяснилось, что Xcode копировал debug framework строится в сборках релизов, но, судя по всему, создает dSYM из правильных исполняемых файлов.

Это несмотря на то, что Xcode использовался для добавления зависимостей структуры от рабочей области. В конце концов я выяснил, почему: по какой-то причине рамки были включены в проект с их местоположением «Относительно группы». После того, как я убедился, что все были «Относительно сборки продукта», он решил проблему для меня. Не сказать, что это единственная возможная причина, но стоит проверить все пути в журнале сборки, потому что Xcode в этом случае ничего не предупреждает.