crash on method "dateComponentsFromString:timeZone:range:fractionOfSecond"

[hermanccw]

I am getting crash report from the wild that has the following stacktrace.

0 ...    libsystem_kernel.dylib  __pthread_kill + 8
1    libsystem_c.dylib   pthread_kill + 58
2    libsystem_c.dylib   abort + 94
3    libc++abi.dylib     abort_message + 74
4    libc++abi.dylib     __cxa_pure_virtual + 18
5    libicucore.A.dylib  icu::TimeZone::getOffset(double, signed char, int&, int&, UErrorCode&) const + 54
6    libicucore.A.dylib  icu::Calendar::computeFields(UErrorCode&) + 76
7    libicucore.A.dylib  icu::Calendar::complete(UErrorCode&) + 42
8    libicucore.A.dylib  icu::Calendar::get(UCalendarDateFields, UErrorCode&) const + 28
9    CoreFoundation  _CFCalendarDecomposeAbsoluteTimeV + 240
10   CoreFoundation  -[__NSCFCalendar components:fromDate:] + 580
11   TestApp    ISO8601DateFormatter.m line 216
-[ISO8601DateFormatter dateComponentsFromString:timeZone:range:fractionOfSecond:]

This is a result of calling "dateFromString" with a string "2013-10-09T13:00:00Z". This does not crash all the time since I can see that it works for other dates in my logs.

I do however create an instance of ISO8601DateFormatter in my AppDelegate like the following.

(ISO8601DateFormatter*) iso8601DateFormatter {
  if (!_iso8601DateFormatter) {
    _iso8601DateFormatter = [[ISO8601DateFormatter alloc] init];
  }
  return _iso8601DateFormatter;
}

[boredzo]

What calendar and locale (if any) do you provide to the formatter?

What architecture are the crashed users running on?

What OS version are the crashed users running on?

[boredzo]

(Incidentally, the aforementioned test case does pass now that I've fixed the script that runs the iOS tests.)

[rudysuharyadi]

Hi guys, I got this crash happen a lot in our application, here is the log: http://crashes.to/s/ca2bd0ce36e
and here is how we call it

+ (ISO8601DateFormatter *)getISO8601DateFormatter{
    NSTimeZone *timeZone = [NSTimeZone timeZoneForSecondsFromGMT:25200];
    ISO8601DateFormatter *formatter = [[ISO8601DateFormatter alloc] init];
    [formatter setDefaultTimeZone:timeZone];
    [formatter setIncludeTime:YES];

    return formatter;
}

+ (NSString *)stringFromDate:(NSDate *)date{
    ISO8601DateFormatter *formatter = [self getISO8601DateFormatter];
    if (date == nil || [date isKindOfClass:[NSNull class]]) return [formatter stringFromDate:[NSDate dateWithTimeIntervalSince1970:0]];
    else return [formatter stringFromDate:date];
}

+ (NSDate *)dateFromString:(NSString *)string{
    ISO8601DateFormatter *formatter = [self getISO8601DateFormatter];
    if (string == nil || [string isKindOfClass:[NSNull class]]) return [NSDate dateWithTimeIntervalSince1970:0];
    else return [formatter dateFromString:string];
}

The crashes happen randomly, and we unable to figure it out whats the problem. Do you guys have any ideas?

[boredzo]

@rudysuharyadi:

What calendar and locale (if any) do you provide to the formatter?

What architecture are the crashed users running on?

What OS version are the crashed users running on?

Also, please attach the crash log to this bug rather than linking to a site that (a) doesn't work without JavaScript and (b) I have no idea how long that page or that site will last.

[rudysuharyadi]

@boredzo
Hi Peter,

Calendar : Gregorian
Language : English
Region : United States
OS Version : iOS 9.1
Device : iPad Mini 2 so architecture should be arm64?
We use GMT +7 timezone, so we provide [NSTimeZone timeZoneForSecondsFromGMT:25200] to the formatter.
and here's the log:

Thread : Crashed: com.apple.root.default-qos
0  libsystem_kernel.dylib         0x197a57140 __pthread_kill + 8
1  libsystem_pthread.dylib        0x197b2cef8 pthread_kill + 112
2  libsystem_c.dylib              0x1979cab78 abort + 140
3  libsystem_malloc.dylib         0x197a8cd34 free_list_checksum_botch + 438
4  libsystem_malloc.dylib         0x197a8ced8 free_tiny_botch + 84
5  CoreFoundation                 0x1825a5324 __rehashd + 244
6  CoreFoundation                 0x1824943f4 -[__NSDictionaryM setObject:forKey:] + 688
7  MokaDev                        0x10033401c -[ISO8601DateFormatter dateComponentsFromString:timeZone:range:fractionOfSecond:] (ISO8601DateFormatter.m:623)
8  MokaDev                        0x100334914 -[ISO8601DateFormatter dateFromString:timeZone:range:] (ISO8601DateFormatter.m:692)
9  MokaDev                        0x1003348b0 -[ISO8601DateFormatter dateFromString:timeZone:] (ISO8601DateFormatter.m:686)
10 MokaDev                        0x100334864 -[ISO8601DateFormatter dateFromString:] (ISO8601DateFormatter.m:683)
11 MokaDev                        0x1004041c8 +[MOCommonFunction dateFromString:] (MOCommonFunction.m:124)
12 MokaDev                        0x10047b684 __38+[MOUserProfile pullProfileWithBlock:]_block_invoke_3 (MOUserProfile.m:96)
13 MokaDev                        0x1007b08a8 __NR__dispatch_async_block_invoke (NRGCDOverride.m:87)
14 libdispatch.dylib              0x1979096e8 _dispatch_call_block_and_release
15 libdispatch.dylib              0x1979096a8 _dispatch_client_callout
16 libdispatch.dylib              0x197917b40 _dispatch_root_queue_drain
17 libdispatch.dylib              0x1979172dc _dispatch_worker_thread3
18 libsystem_pthread.dylib        0x197b29470 _pthread_wqthread + 1092
19 libsystem_pthread.dylib        0x197b29020 start_wqthread + 4

[boredzo]

@rudysuharyadi, that looks like a different crash. Please create a new issue for it.

[boredzo]

(and, @rudysuharyadi, please attach the entire crash report to your issue—there are often vital clues lurking elsewhere in the crash report besides the crashed thread's stack trace)

[boredzo]

@rudysuharyadi, please try 0.8—it fixes at least your crash.

[rudysuharyadi]

oo, thanks, will try it soon

[revolter]

@boredzo What specific commit fixes this issue? I have a similar crash, though I don't use this library, but I would be interested if this helps me as well.

[boredzo]

@revolter: 98bf9cb

That problem was storing cached NSTimeZones in an NSMutableDictionary, which is not thread-safe, so the memory management was doomed. One proposed fix was (IIRC) to put a lock around it; the other was to switch to NSCache, which is thread-safe.

[revolter]

Awesome explanation, thanks a lot!