Search code examples
iosautomatic-ref-countingreleaseretainnscalendar

iOS NSCalendar Crash - References issue?


I'm seeing a number of crashes, all with slightly different manifestations, but they're all pointing to the same line of code, and I have a hunch but it's a bit outside my comfort-zone so I'd like some help.

The crash is related to NSCalendar's components:fromDate.

In the class in question there's an instance variable for an NSCalendar, and in my init method I call

calendar = [NSCalendar autoupdatingCurrentCalendar];

Later I call:

NSDateComponents *components = [calendar components:myComponents fromDate:myDate];

The above line is where the crash occurs, and when looking at the crash logs I see a combination of errors for this one line:

  • EXC_BAD_ACCESS KERN_INVALID_ADDRESS
  • [__NSCFNumber components:fromDate:]: unrecognized selector sent to instance
  • NSInvalidArgumentException [__NSDate components:fromDate:]: unrecognized selector sent to instance
  • SIGABRT ABORT

I've checked and I'm not changing the calendar variable anywhere other than the initial creation of it inside the init method. As I said I do not modify the calendar variable anywhere in the code and I've not been able to replicate any of the other issues, but I've replicated the second crash by doing something like the following:

NSCalendar *calendar = @5;
NSDateComponents *components = [calendar components:myComponents fromDate:myDate];

Could this be some sort of memory reference issue? I've seen similar issues reported on SO posts from a few years ago pre-ARC (I've never done anything without ARC sadly), where people weren't properly retaining their variables. Could this be some sort of issue where the instance variable isn't properly retained, leaved the memory in a bad state causing these weird and seemingly distinct issues but all in the same place? Any and all information is greatly appreciated.

EDIT: I will add that this is a rare/intermittent crash reported by crashlytics that I haven't been able to replicate to debug locally more than once, which is what leads me to believe it's either a memory management issue or perhaps a threading issue.

SECOND EDIT: I was looking back through some screenshots/log stuff I had back from the one time I was able to catch this issue in Xcode and I think I missed something.

If I set a breakpoint at that line, and print the calendar object:

po calendar
0x14d50a20

If I normally do a po on a brand new [NSCalendar autoupdatingCurrentCalendar] I get:

Auto-updating Calendar [<_NSCopyOnWriteCalendarWrapper: 0x10922ae80>]

Does that mean that in the case where it was just an address the object was lost as I originally expected?


Solution

  • While Ritu hit on this, there's more to it worth mentioning. I'm still not sure if this was a memory issue, a threading issue, or a combination of both (very possible) but getting rid of the instance variable and accessing the autoupdatingCurrentCalendar directly each time I need to solved the issue. This is because calling [NSCalendar autoupdatingCurrentCalendar] returns a unique instance each time, which I wouldn't initially have thought.

    Thus, getting rid of the NSCalendar instance variable and replacing each call to that variable with a call to get the autoupdatingCurrentCalendar would solve any issues accessing the same reference from multiple threads as well as if the object would have otherwise been corrupted, lost, released, etc., for any reason.