CoreLocation.ConnectionClient CFDictionaryApplyFunction Crash

在我们的程序中，一直有一类和CoreLocation模块相关的crash，在ios7.0之前的版本中，这类crash占比不是非常高，在ios7.0及以后，这种类型的crash比例突然飙升，让我们不得不对这种类型的crash加以重视了。

大体上，这类crash的最终函数栈如下：

0  libobjc.A.dylib                0x385f0626 objc_msgSend + 6
1  CoreLocation                   0x2e340c24 ___lldb_unnamed_function1254$$CoreLocation + 288
2  CoreLocation                   0x2e33f624 ___lldb_unnamed_function1194$$CoreLocation + 444
3  libxpc.dylib                   0x38c103a8 _xpc_connection_call_event_handler + 40
4  libxpc.dylib                   0x38c12e66 do_mach_notify_port_destroyed + 122
5  libxpc.dylib                   0x38c12dd0 _Xmach_notify_port_destroyed + 104
6  libxpc.dylib                   0x38c12d46 notify_server + 62
7  libxpc.dylib                   0x38c0e9ce _xpc_connection_mach_event + 1926
8  libdispatch.dylib              0x38ad1f42 _dispatch_mach_msg_invoke + 118
9  libdispatch.dylib              0x38ad4c70 _dispatch_queue_drain + 412
10 libdispatch.dylib              0x38ad1a6a _dispatch_mach_invoke + 78
11 libdispatch.dylib              0x38ad4c70 _dispatch_queue_drain + 412
12 libdispatch.dylib              0x38ad1c6e _dispatch_queue_invoke + 42
13 libdispatch.dylib              0x38ad4c70 _dispatch_queue_drain + 412
14 libdispatch.dylib              0x38ad1c6e _dispatch_queue_invoke + 42
15 libdispatch.dylib              0x38ad55f0 _dispatch_root_queue_drain + 76
16 libdispatch.dylib              0x38ad58dc _dispatch_worker_thread2 + 56
17 libsystem_pthread.dylib        0x38c00c16 _pthread_wqthread + 298

最终crash的函数可能会有几种不同的情况，例如：CoreFoundation/CFBasicHashGetBucket，CoreFoundation/CFDictionaryApplyFunction等，但总体上引起的原因都是一致的。

这一类crash咋一看和我们自己的代码没有什么关系，这正是最让人头疼的地方，因为这会很容易让我们去和这些crash撇清关系，但基本上可以这么说，绝大多数的crash，就算函数栈中没有项目相关代码，也是由于我们自己的代码引起的，这里比较幸运的是，这一系列的crash的都和CoreLocation有关，让我和我的同事把注意力集中在这一块，项目中使用CoreLocation的地方也不多。

由于本类crash在函数栈最终有objc_msgSend的出现，基本上可以确定这是由于内存管理方面的问题引起的，对CoreLocation的使用绝大部分操作集中在对CLLocationManager的操作上，起初我们认为可能是由于我们对CLLocationManager的使用有不符合内存管理的地方，但经过一番检查以后，我们排除了这种可能性。

在网上经过一番搜索以后，我们发现有些老外也遇到了我们类似的问题，有些人解决掉了，有些则没有，有些人通过把CLLocationManager的stopUpdatingLocation的调用和将CLLocationManager的release调用延迟解决了一种类型的crash，但由于他的crash函数栈和我们的看起来很不一样，而且我认为我们遵守了apple的内存使用规范，所以我排除了这种解决方案。

于是我和xj回到我们的crash函数栈上来，尝试恢复出CoreLocation崩溃的那两个函数，但最终无果，apple应该是把相关库的符号表全都不在开放，经过一番思索，我们基本上确定该崩溃发生的原因是位置信息回调时发生的，xj说，位置信息相关的模块属于其他进程，在需要更新位置信息的时候，通过gcd和xpc进行进程间通信，把相关数据传给我们的程序进程，这一知识让我突然有了点思路。

我们的程序中也采用了这样的操作：

[CLLocationManager stopUpdatingLocation];
CLLocationManager = nil;

如果对于回调的通知是一种进程间通信，那么停止位置更新的调用，也需要一定的时间通过进程间通信的方式来通知到位置模块，而下一句操作则会在下一个runloop中把CLLocationManager相关的内存回收掉，那么这之间的时间差就很可能会让回调发生时访问一段无效的内存，那么之前网络上关于延迟release CLLocationManager的操作就也能站得住脚了。有了这样的结论，改起来就容易了，其实关于CLLocationManager，整个程序用一个就行了，不需要进行回收，在相应的需求下调用相应的start和stop操作就能够控制位置更新。

后经验证，在最新的版本中，这一类型的crash已经解决。