Punto di interruzione che indica "objc_autoreleaseNoPool"

Question

Quindi eseguo il debug di un'app in preperation per la sua app in modo da rilasciare e ho attivato un punto di interruzione universale per "Tutte le eccezioni". Da allora, ogni volta che esegue l'applicazione, le stampe della console:

Catchpoint 2 (due) In attesa breakpoint 1 - "objc_exception_throw" risolto

objc [11765]: Oggetto 0x8f18ff0 di classe __NSCFLocale autoreleased senza piscina in posto - solo che perde - rompere l'objc_autoreleaseNoPool() per eseguire il debug

objc [11765]: oggetto 0x8f190a0 di classe __NSCFNumber autoreleased senza piscina in posto - solo che perde - rompere l'objc_autoreleaseNoPool() per eseguire il debug

objc [11765]: Oggetto 0x8f1fef0 di classe __NSCFLocale autoreleased senza piscina in posto - solo che perde - pausa objc_autoreleaseNoPool() per eseguire il debug

Letteralmente stampati 3 volte. Non ho idea di cosa significhi ma sembra male. Tutto il consiglio sarebbe apprezzato.

Answer 1

Nuova Info

ho deciso dove il mio problema sta creando un metodo autorelease swizzled.

Non consiglio di farlo se non si sa cosa si sta facendo, tuttavia questo è quello che ho scoperto.

+ (void) load; //Method is called outside the original autorelease pool. 
+ (void) initialize; // Method is called outside the original autorelease pool. 

NSThread crea il proprio thread, il metodo chiamato deve essere avvolto in una piscina autorelease.

Grand Central Dispatch si occupa dell'adattamento sul pool autorelease quando si utilizzano i comandi "dispatch _...". tuttavia, quando si invia manualmente. potresti volerlo avvolgere in un pool di autorelease.

Inoltre, ARC non gestisce il fatto di farvi sapere che un autorelease avverrà al di fuori di un pool.

Pertanto, se si sta utilizzando ARC e si è certi che si troverà al di fuori del pool autorelease. E non c'è nulla che tu possa fare al riguardo. Dovrai evitare tutti i metodi di convenienza.

utilizzare questo.

[[NSString alloc] initWithFormat:@"%@",myObject]; 

invece di questo

[NSString stringWithFormat:@"%@",myObject]; 

Ciò consentirà al sistema di arco di conservare e rilasciare, ma l'autorelease sottostante fatta con il metodo convenienza verranno saltate in quanto non sarà stato utilizzato il metodo di convenienza.

Spero che questo aiuti.

risposta originale

Ok, io non sento questa domanda è stato risposto con sufficiente dettaglio.

il messaggio che viene presentato è stato

objc[1310]: Object 0x34f720 of class SimpleKeychain autoreleased with no pool in place - just leaking - break on objc_autoreleaseNoPool() to debug 

Il debugger sta indicando un possibile punto di interruzione che vi aiuterà a eseguire il debug la situazione. Ora, mentre questo punto di rottura ha davvero fatto ben poco per aiutare il debug della situazione. Penso che sia importante sapere come aggiungere quel breakpoint al debugger e così ho passato il tempo ad armeggiare con esso (dopo aver setacciato internet e non trovando nulla) fino a quando non sono riuscito a infrangere quell'errore.

È un po 'fastidioso che l'interruzione di tutti gli errori non lo catturi, ma qui ci sono i passaggi per aggiungere il breakpoint al debugger.

prima cosa che voglio fare è selezionare il navigatore punto di interruzione del debugger

cliccando su questa scheda

prossimo si guarda verso la parte inferiore del riquadro di navigazione e premere il pulsante Più

Ciò consentirà di aggiungere manualmente un punto di interruzione.

Ho selezionato un punto di interruzione C++ e inserito il nome del messaggio nel campo di testo del nome.

dopo l'aggiunta di questa eccezione ha fatto in realtà pausa.

Tuttavia questo può o non può essere utile a voi come uno sviluppatore oggettivo. Questo ha fatto irruzione nel codice Assembly.

Purtroppo mostrato solo questo punto nello stack di chiamate per il thread.

e si è scoperto che il problema era perché autorelease una classe chiamata autorelease in una chiamata dispatch_once. e ulteriori indagini hanno rivelato che il carico + (vuoto); il metodo sulla classe è stato chiamato prima di ogni altra cosa.questo viene fatto tramite la funzione call_load_methods ed è al di fuori della discussione sul metodo principale.

per correggere questo, ho solo aggiunto la piscina autorelease wrapper per la chiamata.

un'altra soluzione potrebbe essere quella di aggiungere il pool autorelease all'interno + carico (vuoto); metodo. ma questo era sufficiente per i miei usi.

NOTA: lo aggiungo al post qui perché non mi piace trovare un problema e non riuscire a capire tutti i percorsi per la risposta risultante. Se il debugger ti dice di aggiungere un breakpoint alla funzione elencata, allora ci dovrebbe essere qualche informazione da qualche parte per ottenere quell'informazione. Speriamo che questo riduca la frustrazione di alcuni di quelli là fuori che cercano di trovare questa risposta.

Answer 2

Molti dei metodi nel cacao api restituiscono oggetti autorelocati. In particolare, quei metodi che restituiscono un oggetto che non inizia con init, ad esempio [NSNumber numberWithLong:]. Se non si dispone di una piscina autorelease, tali oggetti saranno trapelati. È possibile trovare ulteriori informazioni sull'uso di NSAutoreleasePool nello documentation.

Answer 3

Significa che è necessario creare un pool di autorelease sul thread che si verifica. Altrimenti, gli oggetti allocati non verranno distrutti (come suggerito dal messaggio). Quindi, interrompi/metta in pausa il simbolo, quindi porta lo stack alla voce del thread (o programma) e aggiungi un pool di autorelease. È tutto.