Как соответствовать отчет катастрофического отказа к сборке
Q: Как я могу знать, является ли сборка, которую я тестирую, той же сборкой, сгенерировавшей определенный отчет катастрофического отказа?
A: При наличии затруднений при репродуцировании проблемы, первый шаг должен удостовериться, что Вы тестируете ту же сборку, показавшую проблему.
Каждая исполнимая программа имеет сборку UUID, однозначно определяющий ее. Крешлоги включают сборку UUID приложения, отказавшего и все библиотеки, загруженные во время катастрофического отказа. Этот документ описывает, как найти и сравнить сборку UUID в отчете катастрофического отказа и развертываемом приложении. При получении крешлога из Анализа Приложения важно удостовериться, что Вы тестируете ту же сборку, которую Вы представили — не тестирование сборки, представленной, общая причина отклонений App Store.
Для получения дополнительной информации см.:
iOS: QA1764: То, как воспроизвести ошибки, сообщило против отправок приложения в магазин
OS X: QA1778: То, как воспроизвести ошибки, сообщило против отправок приложения в магазин Mac.
1) Сочтите сборку UUID в Отчете Катастрофического отказа
Первая строка в»Binary Images:«раздел отчета катастрофического отказа включает сборку UUID, внутри <>, отказавшего приложения.
Концы строки с полным путем исполнимой программы приложения в системе.
Последние части этого пути, после CONTAINER_UUID, точки к исполнимой программе в комплекте приложений, и будут полезны на Шаге 2.
Выборка отчета катастрофического отказа перечисления 1
$ grep --after-context=2 "Binary Images:" Example.crash |
Binary Images: |
0xb6000 - 0xb7fff +Example armv7 <270a9b9d7a333a4a9f1aaf8186f81394> /var/mobile/Applications/28D4F177-D312-4D3B-A76C-C2ACB4CB7DAD/Example.app/Example |
0x2feb5000 - 0x2fed6fff dyld armv7 <4a817f3e0def30d5ae2032157d889c1d> /usr/lib/dyld |
Здесь, сборка, которая UUID 270a9b9d7a333a4a9f1aaf8186f81394, и путь к исполнимой программе приложения, является Example.app/Example. 28D4F177-D312-4D3B-A76C-C2ACB4CB7DAD CONTAINER_UUID, и может быть проигнорирован.
2) Сочтите сборку UUID двоичного файла приложения
Можно счесть сборку UUID исполняемого файла с помощью
Команда Listing 2 Terminal для печати сборки исполнимой программы UUID
$ xcrun dwarfdump --uuid <PATH_TO_APP_EXECUTABLE> |
Файл в PATH_TO_APP_EXECUTABLE должен быть исполняемый файл, не пакет .app или .ipa файл.
Если у Вас есть .ipa файл, необходимо извлечь пакет .app в нем. Измените расширение файла от .ipa до .zip, затем распакуйте заархивированный файл и получите пакет .app от получающегося Payload каталог.
Для взгляда в пакете .app щелкните правой кнопкой по нему в Средстве поиска и выберите «Show Package Contents».
приложения для iOS обычно имеют свой исполняемый файл на первом уровне их пакета .app. Ищите файл с «Видом» «Исполняемого файла Unix» в Средстве поиска.
Приложения OS X обычно имеют свой исполняемый файл в каталоге Contents/MacOS/ в их пакете .app.
Пример перечисления 3 нахождения сборки UUID файла IPA, с помощью Терминала
$ # Give a copy of the ipa file a .zip extension. |
$ cp Example.ipa Example.zip |
$ |
$ # open the zip file |
$ unzip Example.zip |
Archive: Example.zip |
creating: Payload/ |
creating: Payload/Example.app/ |
creating: Payload/Example.app/_CodeSignature/ |
inflating: Payload/Example.app/_CodeSignature/CodeResources |
inflating: Payload/Example.app/embedded.mobileprovision |
creating: Payload/Example.app/en.lproj/ |
inflating: Payload/Example.app/en.lproj/InfoPlist.strings |
inflating: Payload/Example.app/en.lproj/ViewController.nib |
inflating: Payload/Example.app/Example |
inflating: Payload/Example.app/Info.plist |
extracting: Payload/Example.app/PkgInfo |
inflating: Payload/Example.app/ResourceRules.plist |
$ |
$ # go look inside the Payload directory to find the app |
$ cd Payload |
$ ls |
Example.app |
$ |
$ # print the build UUID of the app's executable file |
$ xcrun dwarfdump --uuid Example.app/Example |
UUID: 270A9B9D-7A33-3A4A-9F1A-AF8186F81394 (armv7) Example.app/Example |
В этом примере сборка приложения UUID является 270A9B9D 7A33 3A4A 9F1A AF8186F81394.
Больше чем Одна сборка UUID
Можно видеть dwarfdump распечатайте больше чем одну сборку UUID. Это означает, что исполнимая программа является толстым двоичным файлом (также известный как «мультиархитектура» или «универсальный» двоичный файл). Для использования в своих интересах более новой оптимизации CPU, при пребывании совместимыми с более старыми аппаратными средствами, толстые двоичные файлы комбинируют различные сборки (названный частями) приложения в одну исполнимую программу. Каждая часть создается по-другому для каждой архитектуры ЦП. Когда толстый двоичный файл будет выполнен, только одна часть от него будет фактически выполняться.
Различия в, как часть была создана, могут измениться, как ошибка ведет себя. Например, переменные могут быть сохранены при различных смещениях в памяти при создании для различного CPUs. Таким образом, та же ошибка (случайно хранящий один байт мимо конца буфера), могло казаться, изменила значение различной переменной при выполнении различной части.
dwarfdump распечатает архитектуру части, внутри () рядом со сборкой каждой части UUID.
Пример перечисления 4 приложения с многократной сборкой UUIDs
$ xcrun dwarfdump --uuid Example.app/Example |
UUID: 270A9B9D-7A33-3A4A-9F1A-AF8186F81394 (armv7) Example.app/Example |
UUID: 7711EC60-C0B2-3608-A539-182C77AE01ED (armv7s) Example.app/Example |
В этом примере приложение также имеет сборку UUID 7711EC60 C0B2 3608 A539 182C77AE01ED для armv7s архитектуры.
Если Ваше приложение имеет многократную сборку UUIDs, повторите следующий шаг с каждым из них, чтобы видеть, соответствует ли какой-либо из них отчет катастрофического отказа.
3) Сравните сборку UUIDs
UUID, распечатанный dwarfdump находится в немного отличающемся формате, чем используется в крешлоге, это - UPPERCASE и включает четыре «-» символы. Для Вашего здравомыслия можно хотеть преобразовать строки в тот же формат прежде, чем сравнить их.
Пример перечисления 5 использования tr распечатать сборку UUID в нижнем регистре, без тире, для сравнения
$ xcrun dwarfdump --uuid Example.app/Example | tr '[:upper:]' '[:lower:]' | tr -d '-' |
uuid: 270a9b9d7a333a4a9f1aaf8186f81394 (armv7) example.app/example |
$ |
$ # Now that the build UUID is in the crash log format, |
$ # we can just search for it in the crash log to confirm a match |
$ grep 270a9b9d7a333a4a9f1aaf8186f81394 Example.crash |
0xb6000 - 0xb7fff +Example armv7 <270a9b9d7a333a4a9f1aaf8186f81394> /var/mobile/Applications/28D4F177-D312-4D3B-A76C-C2ACB4CB7DAD/Example.app/Example |
В этом примере сборка UUID был в крешлоге, доказывая, что точная сборка генерировала крешлог.
Если Вы не можете определить местоположение заархивированной версии приложения, можно хотеть рассмотреть создание другой сборки путем выполнения этих шагов для приложения для iOS или этих шагов приложение Mac OS X, и перетестирования или перепредставления его.
Связанные документы
То, как воспроизвести ошибки, сообщило против отправок приложения в магазин Mac
То, как воспроизвести ошибки, сообщило против представлений Хранилища приложения для iOS
Тестирование Обновлений приложения для iOS
Понимание и Анализирование Докладов Катастрофического отказа приложения для iOS.
Для шагов для нахождения отчетов катастрофического отказа iOS посмотрите Отладку Развернутые приложения для iOS.
Для получения дополнительной информации об архивации приложения, посмотрите раздел Distributing Applications руководства пользователя Xcode 4.
История версии документа
| Дата | Примечания |
|---|---|
| 24.01.2013 | Термин «сборка идентификатора» был использован в более ранних версиях этого документа для обращения к «сборке UUID» приложения. |
| 12.04.2012 | Новый документ, описывающий, как проверить, какая определенная сборка сгенерировала отчет катастрофического отказа. |