NSDateFormatter crashes when used from different t

问题:

We keep getting a random, weird crash with NSDateFormatter. The relevant stack trace is:

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:] ()

The date formatter is still in memory (i.e. not released or corrupted). The only thing I can think of is the strings upon crash do not conform to the format, but i doubt that will make the formatter completely crash. (it is non trivial to check the format beforehand).

Any thoughts?

回答1:

Thanks to the previous answerers.

This was not a memory problem. It turned out to be a synchronization issue. NSDateFormatters are not thread safe; there was a background thread attempting to use the same formatter at the same time (hence the randomness).

Hope this helps someone in the future!

回答2:

Another solution would be to serialize the execution of the code that uses NSDateFormatters, or any other non-thread-safe objects. Using Grand Central Dispatch you can push the code on the main_queue:

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

or use a private queue to achieve the same effect:

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

回答3:

EXCBADACCESS will occur when you use any deallocated object... Try to use NSZombie.. It is a easy way to find where the EXCBADACCESS occurs... It will specify which Method where and which object gets deallocated

See this Link http://www.markj.net/iphone-memory-debug-nszombie/

回答4:

My bet is that the string you pass in to the date formatter is over-released.

回答5:

I was experiencing weird crashes with _sigtramp which caused to application to appear locked up but still on the screen - completely obstructing the real root cause.

It turned out indeed that we introduced multi-thread data parsing which collided with the main GUI thread trying to parse dates using NSDateFormatter.

Putting some synchronization around the NSDateFormatter formatDate calls resolved the issues.