SIGSEGV SEGV_ACCERR Отчеты о сбоях - Что делать?

Я только что выпустил приложение в AppStore с сообщением о сбоях Crittercism, и у меня появилось довольно много отчетов о сбоях, связанных с ошибкой SIGSEGV. Критерий дает мне StackTrace и несколько удобных подробностей об использовании статистики и т.д. Однако я все еще одурманен этими символизированными трассировками стека. У меня есть несколько вопросов в целом по поводу такого рода вещей -

Многие из классов и методов в Stack Trace даже не используются в моем приложении (насколько мне известно), что заставляет меня думать, что эти сбои связаны с частными API от Apple. Посмотрите на Stack Trace в нижней части этого вопроса. Как я могу сказать, что сбой моего приложения, если все методы и классы в отчете о сбое не реализованы непосредственно в моем коде?
Что означают знаки + с номерами в конце каждой строки в разбитой стойке нити?
Большинство Q/A на StackOverflow, которые спрашивают о сбоях SIGSEGV, говорят, что они вызваны утечками памяти или проблемами, однако как я могу получить сбой из-за проблемы с памятью, если я использую ARC в мой проект iOS? Разве ARC не должен управлять всеми этими вещами для меня?
Что делать, если я не могу реплицировать ошибку/сбой?
Есть ли способ действительно прочитать StackTrace? Есть ли вообще что-нибудь, что было бы полезно для понимания того, что происходит?

Вот StackTrace из отчета о сбоях в главном потоке от Crittercism, к которому относится этот вопрос:

Thread: Unknown Name (Crashed)
0     UIKit                                 0x37307a22 -[UIView(CALayerDelegate) actionForLayer:forKey:] + 138
1     QuartzCore                            0x38fdfff7 -[CALayer actionForKey:] + 75
2     QuartzCore                            0x38fdffa7 _ZL12actionForKeyP7CALayerPN2CA11TransactionEP8NSString + 59
3     QuartzCore                            0x38fdfe93 _ZN2CA5Layer12begin_changeEPNS_11TransactionEjRP11objc_object + 131
4     QuartzCore                            0x38fdab87 _ZN2CA5Layer6setterEj12_CAValueTypePKv + 183
5     QuartzCore                            0x39007057 -[CALayer setBackgroundColor:] + 35
6     UIKit                                 0x3731ef51 -[UIView(Internal) _setBackgroundCGColor:withSystemColorName:] + 1021
7     APP NAME                              0x000a301d 0x00086000 + 118813
8     libdispatch.dylib                     0x3962511f _dispatch_call_block_and_release + 11
9     libdispatch.dylib                     0x39628ecf _dispatch_queue_drain$VARIANT$mp + 143
10   libdispatch.dylib                      0x39628dc1 _dispatch_queue_invoke$VARIANT$mp + 41
11   libdispatch.dylib                      0x3962991d _dispatch_root_queue_drain + 185
12   libdispatch.dylib                      0x39629ac1 _dispatch_worker_thread2 + 85
13   libsystem_c.dylib                      0x3824da11 _pthread_wqthread + 361

Ответ 1

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

fooobar.com/questions/307247/...

Что касается других вещей:

1) Не будьте так быстро, чтобы предположить внутреннюю ошибку API. Ваша функция, очевидно, изменяет цвет фона в представлении, который вызывает различные методы внутри. Вероятно, он каким-то образом получил недопустимое значение. Не будьте настолько наивны, чтобы думать, что код, который вы пишете, является единственным выполняемым кодом.

2) Знаки + указывают смещение этого кода внутри двоичного объекта. Не полезно для вас.

3) С ARC вы можете легко получить ошибку памяти, поскольку ARC использует только область Objective-C. Любые объекты CoreFoundation и т.д. Не будут управляться. Это не обязательно то, что происходит здесь, но ARC не означает, что вы должны перестать думать о памяти все вместе.

4) См. выше

5) См. выше

Ответ 2

Я бы желал, чтобы вы сделали что-то вроде этого:

CALayer *layer = [CALayer layer];
layer.delegate = self;

И тогда ваш объект "я" получил освобождение до того, как последний ref, чтобы CALayer был удален. Свойство delegate не содержит ссылки на объект, который вы задали как значение layer.delegate. Это не имеет никакого отношения к ARC (ARC не волшебным образом фиксирует использование всех указателей в вашем приложении).

Итак, первое, что нужно сделать, это посмотреть на код, в котором вы установите делегат CALayer, и обязательно установите этот делегат обратно в нуль, когда ваш "я" объект будет освобожден. Это нарушит связь CALayer и вашего объекта. В общем, вы должны загрузить свой dsym в Crittercism, но в этом случае это не имеет большого значения.