Il modo migliore per eseguire il debug di un arresto anomalo in objc_msgSend?

Question

Ho un incidente che si verifica quando uno scarico NSAutoreleasePool. Presumibilmente il pool sta cercando di deallocare un oggetto che è stato prematuramente rilasciato da un altro pezzo di codice. Il crash che ho è nel bel mezzo di objc_msgSend mentre sta tentando di inviare un messaggio a un oggetto che non esiste più.

Dato lo stato stack, quali suggerimenti/trucchi/processi/comandi gdb ho a disposizione per ottenere informazioni sull'oggetto in questione e/o sul punto in cui è avvenuta la deallocazione illegittima?

Answer 1

Se si ha la sensazione che sia una cancellazione prematura, abilitare gli zombi a confermare l'ipotesi e quindi eseguire il debug di ciò che sta accadendo. Quando abiliti gli zombi, gli oggetti non vengono realmente distrutti, ma impostati su uno stato zombie, che ti aiuta a rilevare quando sono accessibili dopo che dealloc è stato chiamato. Per saperne di più da NSZombieEnabled

Answer 2

Se si utilizza NSZombieEnabled, è possibile determinare almeno la classe dell'oggetto.

Answer 3

L'articolo definitivo su questo tipo di incidente: http://www.sealiesoftware.com/blog/archive/2008/09/22/objc_explain_So_you_crashed_in_objc_msgSend.html

Answer 4

mi sono imbattuto in quello che sembrava essere un incidente in objc_msgSend. Quello che era ancora più strano era che application:didFinishLaunchingWithOptions: non era nemmeno stato raggiunto prima che si verificasse il cosiddetto crash!

Nel mio caso il crash si è rivelato essere un punto di interruzione che avevo inavvertitamente impostato su un indirizzo di memoria che veniva chiamato prima che il mio codice fosse addirittura raggiunto.

Dopo l'ora o così di cercare di capire questo fuori, ho deselezionato il punto di interruzione, correvo il codice, faccia palming e poi ha continuato la mia giornata facendo finta non era mai successo ...