17

Continuiamo a verificarsi un arresto anomalo casuale con NSDateFormatter. La traccia dello stack rilevante è:NSDateFormatter si arresta in modo anomalo se utilizzato da thread diversi

Program received signal: “EXC_BAD_ACCESS”. 
#0 0x00000005 in ??() 
#1 0x0213e3c3 in udat_parse() 
#2 0x01d4e1ca in CFDateFormatterGetAbsoluteTimeFromString() 
#3 0x01d4e225 in CFDateFormatterCreateDateFromString() 
#4 0x003e2608 in getObjectValue() 
#5 0x003e2921 in -[NSDateFormatter getObjectValue:forString:errorDescription:]() 
#6 0x003e21cd in -[NSDateFormatter dateFromString:]() 

Il programma di formattazione della data è ancora in memoria (cioè non rilasciato o danneggiato). L'unica cosa che posso pensare è che le stringhe su crash non sono conformi al formato, ma dubito che farà in modo che il formattatore si arresti completamente. (Non è banale controllare in anticipo il formato).

Qualche idea?

risposta

43

Grazie ai precedenti utenti.

Questo non era un problema di memoria. Si è rivelato un problema di sincronizzazione. NSDateFormatter s non sono thread-safe; c'era un thread in background che tentava di usare lo stesso formattatore contemporaneamente (quindi la casualità).

Spero che questo aiuti qualcuno in futuro!

+0

grazie mi ha aiutato: D lo stesso problema e si stava verificando solo in modo casuale, grazie mille. –

+1

quindi come lo hai risolto? – user102008

+3

Mi sono assicurato che ogni thread abbia accesso al proprio NSDataFormatter. Se non sei preoccupato per la contesa, probabilmente puoi semplicemente aggiungere '@synchronized (dateFormatter) {...}' attorno al codice che lo usa. – jbenet

1

EXCBADACCESS si verifica quando si utilizza qualsiasi oggetto deallocato ... tenta di utilizzare NSZombie .. E 'un modo semplice per trovare dove si verifica l'EXCBADACCESS ... Sarà specificare il metodo di dove e quale oggetto viene deallocato

Vedere questo collegamento http://www.markj.net/iphone-memory-debug-nszombie/

+1

EXC_BAD_ACCESS non si verifica solo su oggetti deallocati. Significa qualsiasi accesso a una cattiva memoria (come un segfault!). Certo, nella maggior parte dei casi, i problemi di memoria di iPhone sono sovra-rilasci, ma in questo caso si è rivelato un problema di sincronizzazione: i puntatori venivano modificati da diversi thread che conducevano a un denotatore di puntatori falsi. – jbenet

+0

grazie per aver cercato di aiutare però :) – jbenet

1

La mia scommessa è che la stringa che si passa alla formattazione della data è sovra-rilasciata.

+0

Ho controllato questo, molte volte. Sia il formattatore che la stringa non vengono sovra-rilasciati. Si è rivelato un problema di sincronizzazione! – jbenet

3

Un'altra soluzione potrebbe essere serializzare l'esecuzione del codice che utilizza NSDateFormatter s o qualsiasi altro oggetto non thread-safe. Utilizzando Grand Central Dispatch si può spingere il codice a main_queue:

dispatch_async(dispatch_get_main_queue(), ^(void){ 
    [some_object some_message]; 
}); 

o utilizzare una coda privata per ottenere lo stesso effetto:

dispatch_queue_t dispatch_queue = dispatch_queue_create("com.MyApp.serializer",NULL); 
dispatch_async(dispatch_queue, ^(void){ 
    [some_object some_message]; 
}); 
+0

Dopo test delle prestazioni, questa soluzione risulta essere due volte più veloce nel mio (semplice) attuazione, con memorizzazione locale dei thread. Il test delle prestazioni chiama 'stringFromDate:' da più thread. – Berik

1

stavo sperimentando crash strane con _sigtramp che ha causato alla domanda di appaiono bloccati ma ancora sullo schermo - ostruendo completamente la vera causa alla radice.

Si è infatti scoperto che abbiamo introdotto l'analisi dei dati multi-thread che si è scontrata con il thread GUI principale cercando di analizzare le date utilizzando NSDateFormatter.

Mettere un po 'di sincronizzazione intorno al formato NSDateFormatter Le chiamate di data hanno risolto i problemi.

Problemi correlati