iTunesConnect crashlog está parcialmente simbolizado; no muestra los números de línea

Question

El registro de fallas en iTunes Connect para mi aplicación XCode 3.2.5 muestra los nombres de los métodos, pero no los números de línea. Por ejemplo, en el informe de bloqueo abreviada que he pegado en adelante, se muestra esto:

0x000f5ef8 -[MyTableViewController dealloc] + 120

Hay dos cosas aquí que me son desconcertantes, sobre la cual se lo agradecería una cierta penetración. El primero es por qué el archivo .crash sin formato procedente de iTunesConnect ya está parcialmente simbolizado: muestra la clase y el nombre del método, pero no el archivo del código fuente y el número de línea. Esperaría que el crashlog crudo de iTunesConnect muestre apenas las direcciones del hexadecimal. Tal como lo entiendo, solo una vez descargo el registro de fallos en mi sistema local y lo vinculo explícitamente usando la herramienta apropiada (XCode Organizer, symbolicatecrash, atos, gdb x/i, etc.) y los archivos binarios y dSYM de la aplicación exacta (aquellos que tienen el UUID correspondiente), veré los símbolos completos de clase, método, archivo de código fuente y número de línea. Incluso cuando descargo y veo el registro de fallos en un cuadro de Windows, aparece parcialmente simbolizado. Me preocupa que mi distribución binaria incluya incluyendo algunos símbolos de depuración para que esta información aparezca en el registro de fallas sin procesar, a pesar de tener el "Proyecto vinculado al Strip" establecido en su configuración de Destino de distribución. Cualquier idea aquí sería genial.

Lo segundo que me deja perplejo, y que me preocupa más al solucionar este problema de alto perfil, es este asunto del offset. He localizado cuidadosamente el binario dSYM y la aplicación con el UUID correspondiente, los puse en mi directorio de inicio para que Spotlight et al los puedan encontrar, y no importa lo que haga, no puedo convertir ese offset [MyTableViewController dealloc] + 120 en una fuente archivo de código (que me consta que es MyTableViewController.m) y un número de línea. He probado los siguientes trucos con el archivo iTunesConnect .crash prima:

• XCode Organizador: su "symbolication" afecta a ningún cambio en la crashlog - es la misma.
• symbolicatecrash: En realidad, no se queja de nada en modo detallado, y la crashlog salida es la misma
• GDB: Utilizando el mismo BGF y el ajuste -arch que Xcode 3.2.5 utiliza para producir la acumulación de distribución, y cargando en la aplicación coincidente símbolos binarios y dSYM por los comandos this post, gdb 'x/i' e 'info line *' me dice que [MyTableViewController dealloc] + 120 corresponde a una pieza totalmente no relacionada de nuestro código en un archivo completamente diferente - un archivo .h, ¡incluso! Búsqueda inútil.

Algo no está bien aquí. Incluso a pesar de garantizar exactamente el mismo UUID en todo el informe de fallos, el archivo binario de la aplicación y el archivo dSYM ... ninguna de estas herramientas puede arrojar un número de línea real, y hacerlo a bajo nivel me pone en una loca búsqueda. Saber el número de línea exacto es fundamental para solucionar esto, porque no podemos reproducir este bloqueo interno, así que estamos volando a ciegas aquí. Parece ser un objeto simple sobreexplotado, pero no está claro qué objeto exacto es, y no podemos distinguirlo del contexto. Me pregunto si hay alguna configuración de compilación de Xcode indebidamente que de alguna manera está rompiendo el proceso de simbolización.

¡Gracias por su tiempo!

Lo que sigue es el registro de descarga sin procesar abreviado de iTunes Connect.

Incident Identifier: 09EAE058-7D55-4AE5-947A-17280FB0211A 
Hardware Model:  iPhone3,1 
Process:   MyApp [1895] 
Path:   /var/mobile/Applications/B4B872EF-CB0D-41D7-A7B5-435ADE479D0A/MyApp.app/MyApp 
Identifier:  MyApp 
Version:   ??? (???) 
Code Type:  ARM (Native) 
Parent Process: launchd [1] 

Date/Time:  2011-01-24 14:06:32.941 -0500 
OS Version:  iPhone OS 4.2.1 (8C148) 
Report Version: 104 

Exception Type: EXC_BAD_ACCESS (SIGSEGV) 
Exception Codes: KERN_INVALID_ADDRESS at 0xd0000000 
Crashed Thread: 0 

Thread 0 Crashed: 
0 libobjc.A.dylib     0x33479466 objc_msgSend + 18 
1 MyApp      0x000f5ef8 -[MyTableViewController dealloc] + 120 
2 CoreFoundation     0x33a26f74 -[NSObject(NSObject) release] 
3 libobjc.A.dylib     0x3347a812 objc_setProperty 
4 UIKit       0x320bb4a0 -[UINavigationController setDisappearingViewController:] 
5 UIKit       0x320bb478 -[UINavigationController _clearLastOperation] 
xx SNIP xx 
23 MyApp      0x00014eac main + 36 
24 MyApp      0x0000b324 start + 44 

XX SNIP xx 

Binary Images: 
    0x1000 - 0x1e3fff +MyApp armv7 <5570f8eee3bc11647732c12f96fe9553> /var/mobile/Applications/B4B872EF-CB0D-41D7-A7B5-435ADE479D0A/MyApp.app/MyApp 

Answer 1

que he experimentado problemas similares con la liberación de objeto que no fueron retenidas o que se encontraban en una piscina autorelease de ese modo que se publique dos veces.En la mayoría de los casos, me chocaré por una ubicación que esté dentro del framework/iOS, pero fue causada por la falta de una gestión de memoria adecuada. No estoy diciendo que esto esté sucediendo aquí, pero es algo que he experimentado cuando se presentó un error similar.