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