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

Я использую 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 ручки symbolicating отчеты о сбоях для меня автоматически? Почему я не получаю номера строк или методы? И почему мои коды исключений 0x00000000?

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

источник

2012-05-22 Snowman

Вы пытались запустить отчет о сбое через [atos] (https://developer.apple.com/library/mac/#documentation/Darwin/Reference/Manpages/man1/atos.1.html)? – lottscarson

Да, я попробовал метод, найденный в ссылке выше, которая является методом atos, но любой адрес памяти, который я набираю после 'atos -arch armv7 -o 'myapp.app'/'myapp' MEMORY ADDRESS', он просто записывает все Я набираю адрес для памяти, поэтому здесь будет MEMORY ADDRESS – Snowman

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

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

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

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

Грохот само по себе могло быть установка значения NSDictionary до, например, нулевой ключ.

источник

2012-05-22 18:43:03 Kerni

К счастью, для версии 4.3.2 Xcode для меня журналы обозначаются номерами строк и без текущего архивирования сборки, при этом для «Конфигурация Debug» задано значение «НЕТ» для «Конфигурация Debug». –

Затем dSYM по-прежнему доступен на вашем Mac. Скрипт символики ищет его с помощью прожектора. Символы, входящие в исполняемый файл, не содержат номера строк. Никогда. – Kerni

имеет смысл, спасибо. –

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

mdimport .

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

источник

2012-09-24 22:46:27 ruxy

Это отлично работает для приложения, которое у меня есть на рынке. Brilliant! Что привело вас к этому? – paiego

Это отлично сработало для меня. –

Работал и для меня! Благодаря! –

Я не мог заставить XCode 4.5.1 символизировать, перетащив отчет о сбое в Органайзер-> Устройства-> Библиотека-> Журналы устройств.

Не удалось получить символический адрес сбоя, указав 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

источник

2012-10-22 21:37:02 cshavit

Что касается вашего вопроса об исключении кодов ...

Exception Codes: 0x00000000, 0x00000000

... this Apple Technical Note мог бы ответить на ваш вопрос. Короче говоря, этот отчет о сбоях не был сформирован стандартным документированным краш-типом.

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

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

источник

2012-12-19 05:21:33 paiego

Использовать вместо Crashlytics.

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

источник

2012-12-19 05:26:09

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

ответ

Смежные вопросы