2012-04-01 9 views
6

Ho Xcode 4.3.1, iOS 5.1 e ho ARC attivato per creare la mia app.funziona correttamente con il debug build, ma si verifica un arresto anomalo durante la creazione del rilascio, quali potrebbero essere le possibili ragioni?

Ora l'app funziona correttamente in debug build, ma si arresta in modo anomalo durante la build di rilascio. Quale potrebbe essere la possibile ragione della differenza? Mi baso esclusivamente su ARC per la gestione delle risorse. Ho guardato il registro di crash, sta indicando che la memoria che faceva riferimento era già stata rilasciata. Quali saranno le insidie ​​più comuni che potrebbero causare il problema nella build di vendita al dettaglio, quando si utilizza ARC?

Quello che segue è quello che ho ottenuto da crash log

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

EDIT

destinazione di distribuzione del app è iOS 5.0. Uso le connessioni Internet, l'arresto anomalo corrente si verifica nel momento in cui "esegue il rendering" dei dati restituiti dal servizio Web per poter essere visualizzati su un UITableViewController. L'intera app utilizza ARC, ad eccezione di alcuni file di origine di terze parti per i quali è stato disattivato ARC.

+0

Pls fornisce ulteriori suggerimenti, obiettivo di distribuzione? Stai utilizzando le connessioni a Internet? Tutta la tua classe usa ARC o solo alcuni di loro? – Andrea

+0

fatto, si prega di vedere gli aggiornamenti sopra – tom

+0

Penso che sia meglio testare la tua app utilizzando strumenti zombie sul sim. Il fatto che si mischino le classi ARC e non ARC potrebbe causare alcuni problemi nell'utilizzo di schemi di delega o di notifica. È difficile capire perché sta accadendo solo sul dispositivo e non sulla sim, ma probabilmente è dovuto alle differenze hardware tra i due. – Andrea

risposta

0

io possa non avere la risposta, ma ho intenzione di elencare alcuni intuizioni per provare:

  • Assicurarsi che non sta passando gli oggetti in modalità senza un "manico" su di esso dalla tua parte . E l'esempio passerebbe un'istanza di classe del gestore a un metodo che si aspetta un delegato. Il metodo non mantiene quell'istanza e quindi viene rilasciato prima che invochi il metodo.
  • Controlla le macro del pre-compilatore che sono sicure per entrambi i build di DEBUG & RELEASE. Un buon esempio è avere un'istruzione if su una macro che viene rimossa nei build di rilascio e l'istruzione if non la copre con parentesi graffe.
  • Se si dipende dalle definizioni del compilatore per abilitare/disabilitare determinate parti del codice (tramite l'uso delle condizioni #if) assicurarsi che quelle necessarie siano impostate nella configurazione della build.

Se riesco a pensare di più, cercherò di aggiungerli.

4

Ogni volta che ciò accade a me sembra essere perché le build di rilascio sono più aggressive nel chiarire i riferimenti deboli. Se assegni erroneamente qualcosa a una proprietà debole (ad esempio, se aggiungi sottoview a cui manterrai anche riferimenti deboli) prima che tu abbia un forte riferimento ad esso, questo può funzionare su debug e fail alla release. Per esempio (pseudocodice)

@property (weak) UILabel * label; 
... 
self.label = [[UILabel alloc] init]; 
[self.view addSubview:self.label]; 
... 
self.label.text = @"hello"; 

Ho visto questa causa si blocca male di accesso sul rilascio costruisce e non dare nell'occhio su debug.

+0

sì, questo potrebbe sicuramente portare ad un incidente ed è un errore. non dovresti mai SOLO avere un debole riferimento. –

0

Hai un obiettivo diverso per il rilascio e il debug? Controllare se tutti i file sono referenziati correttamente per la destinazione di rilascio.

Nel nostro caso, una categoria su UIButton non è stata vista dal target di rilascio. Una build ad-hoc è andata bene, fino a quando qualcuno ha invocato un metodo implementato da quella categoria. Dal momento che non abbiamo archiviato un archivio dal build Ad-Hoc, non c'era modo di eseguire il debug di un arresto anomalo.(lezione appresa)

Non sicuro se è elencato come EXC_BAD_ACCESS in un registro di arresto anomalo, ma potrebbe aiutare qualcuno a identificare il loro arresto specifico di rilascio.