Почему мои отчеты о сбоях не обозначены?

Я использую Xcode 4.3.1. Сбой произошел на моем устройстве, поэтому я подключаю его и открываю Organizer, перехожу в журналы устройств, нахожу отчет о сбое, и вот что он читает:

Exception Type:  EXC_CRASH (SIGABRT)
Exception Codes: 0x00000000, 0x00000000
Crashed Thread:  0

Last Exception Backtrace:
0   CoreFoundation                  0x3514488f __exceptionPreprocess + 163
1   libobjc.A.dylib                 0x3656b259 objc_exception_throw + 33
2   CoreFoundation                  0x35144789 +[NSException raise:format:] + 1
3   CoreFoundation                  0x351447ab +[NSException raise:format:] + 35
4   CoreFoundation                  0x350b168b -[__NSCFDictionary setObject:forKey:] + 235
5   myapp                           0x0015b4a7 0xe8000 + 472231
6   myapp                           0x0018add1 0xe8000 + 667089
7   myapp                           0x0013cd5b 0xe8000 + 347483
8   Foundation                      0x30ffb60d __NSFireTimer + 145
9   CoreFoundation                  0x35118a33 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 15
10  CoreFoundation                  0x35118699 __CFRunLoopDoTimer + 365
11  CoreFoundation                  0x3511726f __CFRunLoopRun + 1207
12  CoreFoundation                  0x3509a4a5 CFRunLoopRunSpecific + 301
13  CoreFoundation                  0x3509a36d CFRunLoopRunInMode + 105
14  GraphicsServices                0x36396439 GSEventRunModal + 137
15  UIKit                           0x32190e7d UIApplicationMain + 1081
16  myapp                           0x000f6aff 0xe8000 + 60159
17  myapp                           0x000e9370 0xe8000 + 4976


Thread 0 name:  Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0   libsystem_kernel.dylib          0x34f3832c __pthread_kill + 8
1   libsystem_c.dylib               0x36e34208 pthread_kill + 48
2   libsystem_c.dylib               0x36e2d298 abort + 88
3   libc++abi.dylib                 0x30af9f64 abort_message + 40
4   libc++abi.dylib                 0x30af7346 _ZL17default_terminatev + 18
5   libobjc.A.dylib                 0x3656b350 _objc_terminate + 140
6   libc++abi.dylib                 0x30af73be _ZL19safe_handler_callerPFvvE + 70
7   libc++abi.dylib                 0x30af744a std::terminate() + 14
8   libc++abi.dylib                 0x30af881e __cxa_rethrow + 82
9   libobjc.A.dylib                 0x3656b2a2 objc_exception_rethrow + 6
10  CoreFoundation                  0x3509a506 CFRunLoopRunSpecific + 398
11  CoreFoundation                  0x3509a366 CFRunLoopRunInMode + 98
12  GraphicsServices                0x36396432 GSEventRunModal + 130
13  UIKit                           0x32190e76 UIApplicationMain + 1074
14  myapp                           0x000f6af8 0xe8000 + 60152
15  myapp                           0x000e9368 0xe8000 + 4968

Я думал, что Xcode обрабатывает символические отчеты о сбоях для меня автоматически? Почему я не получаю номера строк или методы? И почему мои коды исключений 0x00000000?

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

Ответ 1

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

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

atos -arch armv7 -o 'appname.app.dSYM' 0x0015b4a7

Сама авария могла устанавливать значение NSDictionary, например, ключ nil.

Ответ 2

В надежде, что это может помочь кому-то другому с той же проблемой, для меня работала следующая команда в каталоге архива (выглядит как /Users/my _user/Library/Developer/Xcode/Archives/2012-09- 24, поэтому cd вон там)

mdimport .

Попробуйте запустить symbolicatecrash script после этого. В XCode перейдите в свой Органайзер, Журналы устройств и выберите "Re-Symbolicate Log", щелкнув правой кнопкой мыши по журналу сбоев.

Ответ 3

Я не мог заставить XCode 4.5.1 символизировать, перетащив отчет о сбое в Organizer- > Devices- > Library- > Logging.

И я не мог получить символический адрес сбоя, указав dSYM на сообщение выше @Kerni.

Я использовал atos, но я мог заставить его работать, указав полный путь к файлу символа внутри файла xcarchive (фактически это каталог). Пример:

cd dir_where_the_xcarchive_is
atos -arch armv7 -o myApp\ 9-18-12\ 5.28\ PM.xcarchive/dSYMs/myApp.app.dSYM/Contents/Resources/DWARF/myApp   0x0001943a

Ответ 4

Относительно вашего вопроса об кодах исключений...

Exception Codes: 0x00000000, 0x00000000

... это Техническая нота Apple Можете ответить на ваш вопрос. Короче говоря, этот отчет о сбоях не генерируется стандартным документированным типом аварий.

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

Код исключения 0x8badf00d указывает, что приложение было завершено iOS, поскольку произошел тайм-аут сторожевого таймера. Приложение слишком много времени для запуска, прекращения или реагирования на системные события. Один Общей причиной этого является синхронное взаимодействие на основной нить. Код исключения 0xbad22222 указывает, что VoIP приложение было прекращено iOS, потому что оно возобновилось часто. Код исключения 0xdead10cc указывает, что приложение прекращено iOS, поскольку оно удерживается в системе ресурс (например, база данных адресной книги) во время работы в задний план. Код исключения 0xdeadfa11 показал, что приложение было принудительно прекращено пользователем. Силовые броски возникают, когда пользователь сначала удерживает кнопку "Вкл./Выкл.", пока "слайд отключится", появляется, затем удерживает кнопку "Домой". Разумно предположить что пользователь сделал это, потому что приложение стало не отвечает, но это не гарантировано - сила бросить будет работать на любом приложение.

Ответ 5

Используйте Crashlytics.

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