iOS Crash Report - как найти место сбоя
Наконец я загрузил приложение в appstore. Я использую также аналитику Flurry, и там было зафиксировано несколько ошибок.
Я попытался прикрепить файл dSYM, чтобы сделать его более читабельным, однако я не уверен, какая часть такого журнала преобразуется в текст, читаемый человеком.
Другое дело: я не вижу ни одной строки, указывающей на один из моих файлов классов (реализация).
Итак, мои вопросы: как я могу получить больше информации из такого отчета? - Правда ли, что приложение действительно рухнуло на пользовательском устройстве? Или, может быть, такая ошибка была невидима для пользователя? - Возможно ли, что приложение не зависало, но, возможно, пользователь убил его процесс?
Спасибо
Вот отчет о сбое
Hardware Model: iPhone3,3
Process: my-app [560]
Path: /var/mobile/Applications/3539397F-14A1-4802-A388-1D5070404D98/my id
Identifier: /my id
Version: 1.3
Code Type: ARM
Parent Process: launchd [1]
Exception Type: SIGSEGV
Exception Codes: SEGV_ACCERR at 0x70000008
Crashed Thread: 0
Thread 0 Crashed:
0 libobjc.A.dylib 0x34dde5b0 +[Protocol load] + 663
1 UIKit 0x3471b4a7 0x34699000 + 533671
2 UIKit 0x346b1abb 0x34699000 + 101051
3 UIKit 0x347268d7 0x34699000 + 579799
4 QuartzCore 0x34cdabd9 -[CALayer dealloc] + 1244
5 libdispatch.dylib 0x3793d4b7 0x3793c000 + 5303
6 libdispatch.dylib 0x3793edcb -[OS_object release] + 274
7 CoreFoundation 0x3826af3b +[__NSCFLocale automaticallyNotifiesObserversForKey:] + 12398
8 CoreFoundation 0x381ddebd -[__NSDate timeIntervalSinceReferenceDate] + 500
9 CoreFoundation 0x381ddd49 -[__NSDate timeIntervalSinceReferenceDate] + 128
10 GraphicsServices 0x3887a2eb 0x38875000 + 21227
11 UIKit 0x346f0301 0x34699000 + 357121
12 my-app 0x0012987b -[ASIHTTPRequest setSynchronous:] + 86
Thread 1:
0 libsystem_kernel.dylib 0x3568c648 0x3568b000 + 5704
1 libdispatch.dylib 0x3793fdf8 -[OS_object _dispose] + 579
Thread 2:
0 libsystem_kernel.dylib 0x3568beb4 0x3568b000 + 3764
1 CoreFoundation 0x3826c045 +[__NSCFLocale automaticallyNotifiesObserversForKey:] + 16760
2 CoreFoundation 0x3826ada3 +[__NSCFLocale automaticallyNotifiesObserversForKey:] + 11990
3 CoreFoundation 0x381ddebd -[__NSDate timeIntervalSinceReferenceDate] + 500
4 CoreFoundation 0x381ddd49 -[__NSDate timeIntervalSinceReferenceDate] + 128
5 WebCore 0x3689ca75 +[WebScriptObject initialize] + 608
6 libsystem_c.dylib 0x364f5311 0x364e4000 + 70417
Thread 3:
0 libsystem_kernel.dylib 0x3568beb4 0x3568b000 + 3764
1 CoreFoundation 0x3826c045 +[__NSCFLocale automaticallyNotifiesObserversForKey:] + 16760
2 CoreFoundation 0x3826ada3 +[__NSCFLocale automaticallyNotifiesObserversForKey:] + 11990
3 CoreFoundation 0x381ddebd -[__NSDate timeIntervalSinceReferenceDate] + 500
4 CoreFoundation 0x381ddd49 -[__NSDate timeIntervalSinceReferenceDate] + 128
5 Foundation 0x3264cbcd +[NSURLConnection _resourceLoadLoop:] + 308
6 Foundation 0x326d067d -[NSThread description] + 1096
7 libsystem_c.dylib 0x364f5311 0x364e4000 + 70417
Thread 4:
0 libsystem_kernel.dylib 0x3568beb4 0x3568b000 + 3764
1 CoreFoundation 0x3826c045 +[__NSCFLocale automaticallyNotifiesObserversForKey:] + 16760
2 CoreFoundation 0x3826ada3 +[__NSCFLocale automaticallyNotifiesObserversForKey:] + 11990
3 CoreFoundation 0x381ddebd -[__NSDate timeIntervalSinceReferenceDate] + 500
4 CoreFoundation 0x381ddd49 -[__NSDate timeIntervalSinceReferenceDate] + 128
5 my-app 0x001275eb +[ASIHTTPRequest runRequests] + 170
6 Foundation 0x326d067d -[NSThread description] + 1096
7 libsystem_c.dylib 0x364f5311 0x364e4000 + 70417
Thread 5:
0 libsystem_kernel.dylib 0x3569c594 0x3568b000 + 71060
1 libsystem_c.dylib 0x364f5311 0x364e4000 + 70417
Thread 6:
0 libsystem_kernel.dylib 0x3568beb4 0x3568b000 + 3764
1 CoreFoundation 0x3826c045 +[__NSCFLocale automaticallyNotifiesObserversForKey:] + 16760
2 CoreFoundation 0x3826ada3 +[__NSCFLocale automaticallyNotifiesObserversForKey:] + 11990
3 CoreFoundation 0x381ddebd -[__NSDate timeIntervalSinceReferenceDate] + 500
4 CoreFoundation 0x381ddd49 -[__NSDate timeIntervalSinceReferenceDate] + 128
5 Foundation 0x3262378f +[NSNotification allocWithZone:] + 334
6 Foundation 0x326c705d +[NSPropertyListSerialization propertyListWithStream:options:format:error:] + 9132
7 my-app 0x0013a9ad +[TFURLConnectionOperation _runNetworkThread:] + 140
8 Foundation 0x326d067d -[NSThread description] + 1096
9 libsystem_c.dylib 0x364f5311 0x364e4000 + 70417
Thread 7:
0 libsystem_kernel.dylib 0x3569cd98 0x3568b000 + 73112
1 libsystem_c.dylib 0x364eaa16 0x364e4000 + 27158
Thread 8:
0 libsystem_kernel.dylib 0x3569cd98 0x3568b000 + 73112
1 libsystem_c.dylib 0x364eaa16 0x364e4000 + 27158
Thread 0 crashed with ARM Thread State:
r0: 0x1fc42250 r1: 0x34b1bee8 r2: 0x2fdf0d60 r3: 0x348a80d5
r4: 0x70000000 r5: 0x1fc42250 r6: 0x1fc42360 r7: 0x2fdf0e3c
r8: 0x1ed3c720 r9: 0x0d2c6fba r10: 0x1fc1b290 r11: 0x00000001
ip: 0x3b9a7d64 sp: 0x2fdf0db4 lr: 0x3471b84b pc: 0x34dde5b0
cpsr: 0x20000030
2 ответа
По поводу ваших вопросов:
Вопрос 1: Как я могу получить больше информации из такого отчета?
Ответ:
- Сигнал
SIGSEGVчто в основном означает ошибку сегментации. Существует несколько возможных причин такого сбоя, например, переизданный объект, неинициализированный указатель или код, который записывается непосредственно в память. - Разрушающая нить показывает
deallocвызов в трассировку стека. Это указывает на то, что сбой был вызван во время освобождения объекта. - Многие фоновые потоки выполняют сетевую операцию с
ASIHTTPRequestс аналогичными вызовами в стеке следов. - Есть много упоминаний о
automaticallyNotifiesObserversForKeyчто намекает на то, что Key-Value-Observing участвует. Возможно, на ключе зарегистрирован наблюдатель, и наблюдатель уже освобожден. Это еще сложнее, так как уведомления запускаются из фонового потока! Например, налаживание связей в фоновом режиме и наблюдение за объектом в главном потоке. В таких сценариях довольно легко получить такие сбои, если вы не убедитесь, что объект в основном потоке живет достаточно долго. - Это действительно очень странно, что несколько фоновых потоков имеют почти одинаковые трассировки стека с даже одинаковыми адресами памяти для отдельных стековых фреймов.
Предположение: Если вы не можете воспроизвести эту проблему, вы можете не найти причину. Я подозреваю, что это как-то связано с ASIHTTPRequest и либо его внутренняя обработка код-значение-ключ, либо ваше собственное использование. Так что я бы заменил эту библиотеку, например, на AFNetworking или используя простой сетевой стек, предоставляемый iOS. Кроме того, если вы используете кодирование ключ-значение, проверьте код относительно многопоточности.
Вопрос 2: правда ли, что приложение действительно зависло на пользовательском устройстве?
Да, вы получаете эти отчеты только о реальных сбоях приложений.
Вопрос 3: А может, такая ошибка была невидима для пользователя?
Нет, SIGSEGV это настоящий сбой вашего приложения. Invisible будет, если вы поймаете исключение в своем коде и по-прежнему создаете отчет и отправляете его заново. Но, насколько я знаю, Flurry не предоставляет эту функцию, вы, очевидно, не реализовали ее, и этот сбой также не вызван исключением. Так что это невозможно.
Вопрос 4. Возможно ли, что приложение не аварийно завершило работу, но, возможно, пользователь убил его процесс?
Если приложения будут убиты, Flurry не получит отчет о сбое. Убийства инициируются iOS, и библиотеки отчетов о сбоях в процессе (что означает, что каждая сторонняя служба отчетов о сбоях) никогда не смогут создать отчет для них.
Дополнительное примечание: Точки прерывания исключений (как предлагали другие) не помогают при сбоях этого типа, поскольку они не произошли из-за возникновения исключения.
Может быть, спросить прямо на Flurry - crashanalytics@flurry.com? Я надеюсь, что они могут лучше помочь вам с этим.
посмотрите на ваши места, там вы делаете интернет-запросы - я думаю, что-то в этом месте.
Для лучшего тестирования, я думаю, вам нужно найти версию для iPhone3.3 (поскольку я знаю, что это verizon iphone 4) и попытаться отладить ваше приложение непосредственно на этом устройстве.