Il crashlog di iTunesConnect è parzialmente simbolizzato; non mostra i numeri di riga

Question

Il crashlog su iTunesConnect per la mia applicazione XCode 3.2.5 mostra i nomi dei metodi, ma non i numeri di riga. Per esempio, nella relazione crash abbreviata Ho incollato in seguito, mostra questo:

0x000f5ef8 -[MyTableViewController dealloc] + 120

Ci sono due cose qui che mi sono sconcertanti, su cui mi farebbe piacere una certa comprensione. Il primo è il motivo per cui il file .crash raw proveniente da iTunesConnect è già parzialmente simboleggiato: mostra il nome della classe e del metodo, ma non il file del codice sorgente e il numero di riga. Mi aspetterei che il registro degli arresti di iTunesConnect non elaborato mostri solo gli indirizzi esadecimali. A quanto mi risulta, solo una volta ho scaricato il crash log sul mio sistema locale e in modo esplicito legano utilizzando lo strumento appropriato (XCode Organizzatore, symbolicatecrash, Atos, gdb x comando/I, ecc) e per l'esatto binario delle applicazioni e dei file dSYM (quelli che hanno l'UUID corrispondente), vedrò i simboli completi di classe, metodo, file del codice sorgente e numero di linea. Anche quando scarico e visualizzo il crashlog su una finestra di Windows, appare parzialmente simbolizzato. Sono preoccupato che la mia distribuzione binaria deve essere tra cui alcuni simboli di debug in modo che queste informazioni di presentarsi nel crashlog grezzo, pur avendo "Strip progetto legato" impostato nelle sue impostazioni di destinazione di distribuzione. Qualsiasi intuizione qui sarebbe grandiosa.

La seconda cosa che mi lascia perplessi, ed è di preoccupazione più immediata per me nel fissare questo incidente di alto profilo, è questo business dell'offset. Ho localizzato con molta attenzione il binario dSYM e l'applicazione con l'UUID corrispondente, li mise nella mia home directory in modo che possano essere trovati da Spotlight et al, e non importa quello che faccio, non sono in grado di convertire che compensare [MyTableViewController dealloc] + 120 ad una sorgente file di codice (che è noto per essere MyTableViewController.m) e un numero di riga. Ho provato i seguenti trucchi con il file crash di iTunesConnect:

• XCode Organizer: la sua "simbolizzazione" non influisce sul registro degli arresti anomali, è lo stesso.
• symbolicatecrash: In realtà non si lamenta di nulla in modalità dettagliata, e la crashlog uscita è la stessa
• gdb: Utilizzando lo stesso gdb e l'impostazione -arch che XCode 3.2.5 utilizza per la produzione della costruzione di distribuzione, e loading in binario applicazione corrispondente e dSYM simboli al this post, gdb 'x/i' e 'Info Line *' Comandi mi dice che [MyTableViewController dealloc] + 120 corrisponde a un pezzo totalmente estranei della nostra base di codice in un file di completamente diverso - un file .h, anche! Caccia all'oca selvaggia.

qualcosa che non va qui. Anche se assicuriamo lo stesso identico UUID attraverso il rapporto di crash, il file binario dell'applicazione e il file dSYM ... nessuno di questi strumenti può produrre un numero di linea reale, e farlo nel modo a basso livello mi manda su un inseguimento selvaggio. Conoscere il numero esatto della linea è fondamentale per risolvere questo problema, perché non siamo in grado di riprodurre questo crash in-house, quindi stiamo volando qui cieco. Questo sembra essere un semplice oggetto sovrascritto, ma non è chiaro quale sia l'oggetto esatto e non siamo in grado di distinguerlo dal contesto. Mi chiedo se ci sia qualche impostazione di compilazione XCode appropriatamente distorta che sta in qualche modo rompere il processo di simbolizzazione.

Grazie per il vostro tempo!

Quello che segue è il registro .crash raw abbreviato da iTunesConnect.

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

ho sperimentato problemi simili con rilascio di oggetto che non sono state mantenute o che erano in una piscina autorelease in tal modo ottenendo rilasciato due volte.Molto spesso mi capiterà un crash per una posizione all'interno del framework/iOS, ma è stato causato dalla mia mancanza di una corretta gestione della memoria. Non sto dicendo che stia succedendo qui, ma è solo una cosa che ho vissuto quando si è presentato un errore simile.