ios - itunes developer

SIGSEGV SEGV_ACCERR Informes de bloqueos-¿Qué hacer?

Question

Acabo de lanzar una aplicación en la AppStore con informes de fallos de Crittercism y he recibido varios informes de fallos relacionados con un error SIGSEGV. Crittercism me da un StackTrace y algunos detalles prácticos sobre estadísticas de uso, etc. Sin embargo, todavía estoy confundido por estos rastros de pila simbolizados. Tengo algunas preguntas en general sobre este tipo de cosas.

1. Muchas de las clases y métodos de Stack Trace ni siquiera se usan en mi aplicación (que yo sepa), lo que me lleva a creer que estos bloqueos se deben a API privadas de Apple. Eche un vistazo al Stack Trace cerca de la parte inferior de esta pregunta. ¿Cómo puedo saber qué está fallando en mi aplicación si todos los métodos y clases del informe de fallas no están implementados directamente en mi código?

2. ¿Qué significan los signos + con números al final de cada línea en el hilo destrozado?

3. La mayoría de las preguntas y respuestas en StackOverflow que preguntan sobre los bloqueos de SIGSEGV dicen que son causadas por problemas o pérdidas de memoria, sin embargo , ¿cómo puedo tener un bloqueo debido a un problema de memoria si uso ARC en mi proyecto de iOS? ¿No se supone que ARC debe manejar todas esas cosas por mí?

4. ¿Qué debo hacer si no puedo replicar el error / bloqueo?

5. ¿Hay alguna manera de leer realmente un StackTrace? ¿Hay algo en general que sea útil para comprender lo que está sucediendo?

Aquí está el StackTrace del Informe de bloqueo de subprocesos principales de Crittercism al que se refiere esta pregunta:

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

Answer 1

Es necesario simbolizar este informe de bloqueo. El número 7 es la línea en la que estará interesado, pero no hay información de símbolos, por lo que el informe de bloqueo no se puede traducir en algo útil para usted. Para simbolizar, necesita el código exacto que se utilizó en el lanzamiento de su tienda de aplicaciones. Si tienes eso, entonces puedes hacer referencia a esta respuesta:

https://.com/a/13280585/1155387

En cuanto a las otras cosas:

1) No seas tan rápido en asumir un error interno de API. Su función obviamente cambia el color de fondo de una vista, que llama a varios métodos internamente. Probablemente haya pasado un valor inválido de alguna manera. No seas tan ingenuo como para pensar que el código que escribes es el único código ejecutado.

2) Los signos + indican el desplazamiento de ese código dentro del objeto binario. No es útil para ti.

3) Puede tener fácilmente un error de memoria con ARC, porque ARC solo se ocupa del alcance de Objective-C . Cualquier objeto CoreFoundation, etc., no será gestionado. Eso no es necesariamente lo que sucede aquí, pero ARC no significa que deba dejar de pensar en la memoria por completo.

4) ver arriba

5) ver arriba

Answer 2

Estaría dispuesto a ser que hicieras algo como esto:

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

Y luego su objeto "self" se desasignó antes de que se eliminara la última referencia al CALayer. Una propiedad delegada no contiene una referencia al objeto que estableció como el valor layer.delegate. Esto no tiene nada que ver con ARC (ARC no arregla de forma mágica todo el uso del puntero en su aplicación).

Por lo tanto, lo primero que debe hacer es mirar el código en el que establece un delegado CALayer y asegúrese de establecer esta referencia del delegado en cero cuando su objeto "self" se desasigne. Eso romperá la asociación del CALayer y su objeto. En general, deberías subir tu dsym a Crittercism, pero no importará mucho en este caso.