Отчет о сбоях iOS — как найти место сбоя

наконец я загрузил приложение в магазин приложений. Я также использую аналитику 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

ios crash-reports dsym
person MP23    schedule 05.12.2013    source источник
comment
Добавить точку останова исключения в проект. Прочтите эту ссылку blog.manbolo.com/2012 /01/23/xcode-tips-1-break-on-exceptions   -  person Bhumeshwer katre    schedule 05.12.2013
comment
Не используйте ASIHTTPRequest! Библиотека старая и вызывает проблемы. Даже разработчик говорит: Please note that I am no longer working on this library - you may want to consider using something else for new projects. :) См. allseeing-i.com/ASIHTTPRequest.   -  person Kerni    schedule 05.12.2013
comment
Привет, ты решил это? У меня есть очень похожий отчет о сбое. Спасибо.   -  person shawkinaw    schedule 10.02.2014
comment
Да, я решил это. Это было вызвано запросом на отклонение контроллера модального представления и нажатием других контроллеров представления в неправильном порядке. Я отправлю фрагмент кода, который вызывал сбой, как только получу его из старой версии.   -  person MP23    schedule 11.02.2014

Ответы (2)


arrow_upward
1
arrow_downward

Что касается ваших вопросов:

Вопрос 1. Как я могу получить дополнительную информацию из такого отчета?

Отвечать:

  1. Сигнал SIGSEGV, что в основном означает ошибку сегментации. Есть несколько возможных причин такого сбоя, например. перевыпущенный объект, неинициализированный указатель или код, который записывает непосредственно в память.
  2. Сбой потока показывает вызов dealloc в трассировке стека. Это намекает на то, что сбой был вызван, когда объект был освобожден.
  3. Многие фоновые потоки выполняют сетевую операцию с ASIHTTPRequest с похожими вызовами в трассировке стека.
  4. Есть много упоминаний о automaticallyNotifiesObserversForKey, которые намекают на то, что задействуется Key-Value-Observing. Возможно, для ключа зарегистрирован наблюдатель, который уже освобожден. Это еще сложнее, так как уведомления запускаются из фонового потока! Например. создание сети в фоновом режиме и наблюдение за объектом в основном потоке. В этих сценариях довольно легко получить такие сбои, если вы не убедитесь, что объект в основном потоке живет достаточно долго.
  5. Это действительно очень странно, что несколько фоновых потоков имеют почти идентичные трассировки стека даже с идентичными адресами памяти для отдельных кадров стека.

Предположение. Если вы не можете воспроизвести эту проблему, возможно, вы не найдете ее причину. Я подозреваю, что это как-то связано с ASIHTTPRequest и либо с его внутренней обработкой кодирования значений ключа, либо с вашим собственным использованием этого. Поэтому я бы заменил эту библиотеку, например. с AFNetworking или используя простой сетевой стек, предоставляемый iOS. Кроме того, если вы используете ключ-значение, проверьте код на предмет безопасности многопоточности.

Вопрос 2. Правда ли, что приложение действительно аварийно завершает работу на пользовательском устройстве?

Да, вы получаете эти отчеты только о реальных сбоях приложения.

Вопрос 3: А может, такая ошибка была незаметна для пользователя?

Нет, SIGSEGV — это настоящий сбой вашего приложения. Invisible будет, если вы поймаете исключение в своем коде и все равно сгенерируете отчет и отправите его. Но, насколько я знаю, Flurry не предоставляет эту функцию, вы, очевидно, не реализовали ее, и этот сбой также не вызван исключением. Так что это невозможно.

Вопрос 4. Возможно ли, что приложение не аварийно завершило работу, а пользователь убил его процесс?

Если приложения будут убиты, вы не получите отчет о сбое от Flurry. Убийства инициируются iOS, и библиотеки отчетов о сбоях в процессе (что означает, что любая сторонняя служба отчетов о сбоях) никогда не сможет создать для них отчет.

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

person Kerni    schedule 05.12.2013
comment
Спасибо за ваш ответ, нет, у меня есть много мест, чтобы проверить. В моем приложении у меня есть один, скажем, главный наблюдатель - это подкласс TabBarController, однако он не всегда виден (например, когда я модально отображаю контроллер представления). Общая цель моего подкласса TabBarController состоит в том, чтобы предоставлять различные потоки при получении какого-либо уведомления, например, отображать какой-либо экран на вкладке 4 и т. д. На данный момент я подозреваю, что, возможно, этот контроллер освобожден, но все еще зарегистрирован как наблюдатель. - person MP23; 06.12.2013

arrow_upward
0
arrow_downward

можно спросить напрямую по адресу [email protected]? Я надеюсь, что они могут лучше помочь вам с этим.

взгляните на ваши места, где вы делаете интернет-запросы - я думаю, что-то в этом месте.

Для лучшего тестирования, я думаю, вам нужно найти версию iPhone3.3 (насколько я знаю, это Verizon iPhone 4) и попытаться отладить приложение непосредственно на этом устройстве.

person Denis Kozhukhov    schedule 05.12.2013