символизирующие отчеты о сбоях приложений iPad - PullRequest
0 голосов
/ 21 декабря 2010

Здесь я немного новичок в разработке iPad и в объективе-c. У меня проблема с чтением журналов устройства. когда я просматривал журналы, люди говорили, что у меня есть сборка и архивация, и я использую эту сборку для устройства. так что в следующий раз, когда вы подключите устройство к вашей машине, журналы устройства будут автоматически символизировать журналы сбоев. Но это не тот случай.

Шаги, которым я сейчас следую.

  1. поставить устройство конфигурации xcode и отпустить.
  2. Сборка -> Сборка и архив.
  3. Перейдите в папку Build, перетащите бинарный файл на иконку Itunes и выберите замену.
  4. после тестирования заново подключите ipad, перейдите в окно органайзера, выберите устройство, нажмите на журналы устройства.
  5. Здесь показаны только символы ... а не какая-либо подсказка о том, где он разбился.

Например: отчет о сбое

Thread 0 Crashed:
0   libSystem.B.dylib               0x30d7c2d4 __kill + 8
1   libSystem.B.dylib               0x30d7c2c4 kill + 4
2   libSystem.B.dylib               0x30d7c2b6 raise + 10
3   libSystem.B.dylib               0x30d90d72 abort + 50
4   libSystem.B.dylib               0x30d7e980 __assert_rtn + 152
5   libgcc_s.1.dylib                0x307e8b4e _Unwind_SjLj_Resume + 26
6   CoreFoundation                  0x35801d50 CFRunLoopRunSpecific + 432
7   CoreFoundation                  0x35801b88 CFRunLoopRunInMode + 52
8   GraphicsServices                0x320c84a4 GSEventRunModal + 108
9   GraphicsServices                0x320c8550 GSEventRun + 56
10  UIKit                           0x341dc322 -[UIApplication _run] + 406
11  UIKit                           0x341d9e8c UIApplicationMain + 664
12  My EF                           0x00002c84 main (main.m:14)
13  My EF                           0x00002c4c start + 32

Пожалуйста, дайте мне знать, если я делаю что-то не так.

спасибо Суреш

Ответы [ 3 ]

1 голос
/ 18 января 2011

Я тоже это вижу.

Я думаю, что было сгенерировано исключение, которое было зафиксировано в кадрах № 5 или № 6.Затем что-то пошло не так, когда он попытался восстановить исходную трассировку стека, и была вызвана abort ().

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

0 голосов
/ 01 июля 2011

Шаги для анализа отчета о сбое:

1. Скопируйте файл выпуска .app, который был помещен в магазин приложений, файл .dSYM, созданный во время выпуска, и отчет о сбое, полученный из APPLE, в FOLDER.

2. Откройте приложение терминала и перейдите в созданную выше папку (с помощью команды CD).

3.atos -arch armv7 -o '' /'<.dSYM имя файла здесь> '. Местоположение памяти должно быть тем, в котором приложение потерпело крах согласно отчету.

Пример: atos -arch armv7 -o 'имя приложения.app' / 'имя приложения' 0x0003b508

Это покажет вам точную строку, имя метода, которое привело к сбою.

Пример: [имя-класса имя-функции:]; -510

Спасибо

0 голосов
/ 21 декабря 2010

EDIT

Это символизирует ваш код - вы все делаете правильно. вы можете сказать, потому что он говорит, что main.m: 14 говорит вам, что трассировка стека находится в строке 14 main.m

Причина, по которой вы больше ничего не видите, заключается в том, что это не ваш код :) Библиотеки Apple скомпилированы для вас - вы просто связываете их со своим приложением. Он не может сказать вам строку, которая потерпела крах, потому что у вас нет кода!

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

Вдобавок ко мне, вы включили libgcc_s в свой список связанных фреймворков?


Да, это сложно.

Меня поразило то, что это не просто сборка одного и того же кода, это точно такая же сборка, что была установлена ​​в приложении. Восстановление не достаточно хорошо.

Для решения этой проблемы я использую контроль версий (в частности, git). Каждый раз, когда я даю людям версию приложения для тестирования, я копирую папку сборки в каталог release /. Затем я помечаю его тегом (например, release_2010_12_10_showcase), чтобы, если они вернутся с сбоем, я мог спросить их, когда я дал им приложение, и проверить правильную версию сборки. Это означает, что у меня есть символы из сборки в их приложении, и мой код в XCode точно такой же, как код, который они выполняли, так что я могу видеть, где произошел сбой, и исправить его :) Затем, используя магию git, я могу объединить мои изменения в мой последний код:)

NS Я еще не использовал приложения для архивирования - похоже, вы делаете все правильно, но я думаю, что происходит какая-то магия, которую понимает только Apple :) Мне также нравится иметь все в моем контроле версий, и я не недостаточно разбираюсь в архивах в XCode, чтобы с ним было удобно. Хотя это, вероятно, означает, что я должен просто узнать, как они работают!

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