问题描述
我有这个问题通过Crashlytics报告，虽然我无法在本地复制，所以我没有什么可以去除堆栈跟踪下面..不知道如果引用CoreLocation在堆栈跟踪与它有关，但我不知道什么可能是原因。我的项目使用ARC。任何线索？
I've got this issue being reported via Crashlytics, although I've been unable to replicate it locally, so I've got nothing to go on other than the stack trace below.. Not sure if the references to CoreLocation in the stack trace have anything to do with it, but I'm not sure what could possibly be the cause. My project is using ARC. Any clue?
Thread : Crashed: com.apple.CoreLocation.ConnectionClient.0x14eb3510.events
0 CoreFoundation 0x307769a8 CFBasicHashCreateCopy + 712
1 libobjc.A.dylib 0x3afd1a19 object_setClass + 24
2 CoreFoundation 0x30782d0f CFDictionaryCreateMutableCopy + 154
3 CoreLocation 0x30d0a8f3 CLLocationCoordinate2DGetDistanceFrom + 47590
4 CoreLocation 0x30d2d607 CLClientCreateIso6709Notation + 49626
5 CoreFoundation 0x30786d45 __CFDictionaryApplyFunction_block_invoke + 16
6 CoreFoundation 0x30772cd4 CFBasicHashApply + 128
7 CoreFoundation 0x3077be27 CFDictionaryApplyFunction + 154
8 CoreLocation 0x30d2cc25 CLClientCreateIso6709Notation + 47096
9 CoreLocation 0x30d2b625 CLClientCreateIso6709Notation + 41464
10 libxpc.dylib 0x3b5fc3a9 _xpc_connection_call_event_handler + 40
11 libxpc.dylib 0x3b5fee67 do_mach_notify_port_destroyed + 122
12 libxpc.dylib 0x3b5fedd1 _Xmach_notify_port_destroyed + 104
13 libxpc.dylib 0x3b5fed47 notify_server + 62
14 libxpc.dylib 0x3b5fa9cf _xpc_connection_mach_event + 1926
15 libdispatch.dylib 0x3b4bdf43 _dispatch_mach_msg_invoke + 118
16 libdispatch.dylib 0x3b4c0c71 _dispatch_queue_drain + 412
17 libdispatch.dylib 0x3b4bda6b _dispatch_mach_invoke + 78
18 libdispatch.dylib 0x3b4c0c71 _dispatch_queue_drain + 412
19 libdispatch.dylib 0x3b4bdc6f _dispatch_queue_invoke + 42
20 libdispatch.dylib 0x3b4c0c71 _dispatch_queue_drain + 412
21 libdispatch.dylib 0x3b4bdc6f _dispatch_queue_invoke + 42
22 libdispatch.dylib 0x3b4c15f1 _dispatch_root_queue_drain + 76
23 libdispatch.dylib 0x3b4c18dd _dispatch_worker_thread2 + 56
24 libsystem_pthread.dylib 0x3b5ecc17 _pthread_wqthread + 298
这里是另一个，可能相关。
Here is another, likely related.
Crashed: com.apple.CoreLocation.ConnectionClient.0x17665330.events
EXC_BAD_ACCESS KERN_INVALID_ADDRESS at 0x11755e44
Thread : Crashed: com.apple.CoreLocation.ConnectionClient.0x17665330.events
0 libobjc.A.dylib 0x381db626 objc_msgSend + 5
1 CoreFoundation 0x2d979d75 CFDictionaryCreateMutableCopy + 320
2 CoreLocation 0x2df018f3 (null) + 47590
3 CoreLocation 0x2df24607 (null) + 49626
4 CoreFoundation 0x2d97dd05 __CFDictionaryApplyFunction_block_invoke + 16
5 CoreFoundation 0x2d969c94 CFBasicHashApply + 128
6 CoreFoundation 0x2d972de7 CFDictionaryApplyFunction + 154
7 CoreLocation 0x2df23c25 (null) + 47096
8 CoreLocation 0x2df22625 (null) + 41464
9 libxpc.dylib 0x387fb3a9 _xpc_connection_call_event_handler + 40
10 libxpc.dylib 0x387fde67 do_mach_notify_port_destroyed + 122
11 libxpc.dylib 0x387fddd1 _Xmach_notify_port_destroyed + 104
12 libxpc.dylib 0x387fdd47 notify_server + 62
13 libxpc.dylib 0x387f99cf _xpc_connection_mach_event + 1926
14 libdispatch.dylib 0x386bcf43 _dispatch_mach_msg_invoke + 118
15 libdispatch.dylib 0x386bfc71 _dispatch_queue_drain + 412
16 libdispatch.dylib 0x386bca6b _dispatch_mach_invoke + 78
17 libdispatch.dylib 0x386bfc71 _dispatch_queue_drain + 412
18 libdispatch.dylib 0x386bcc6f _dispatch_queue_invoke + 42
19 libdispatch.dylib 0x386bfc71 _dispatch_queue_drain + 412
20 libdispatch.dylib 0x386bcc6f _dispatch_queue_invoke + 42
21 libdispatch.dylib 0x386c05f1 _dispatch_root_queue_drain + 76
22 libdispatch.dylib 0x386c08dd _dispatch_worker_thread2 + 56
23 libsystem_pthread.dylib 0x387ebc17 _pthread_wqthread + 298
推荐答案
坏的内存位置，一个对象应该是。所以我的建议是启用僵尸检测（编辑方案，然后选择诊断选项卡，勾选启用僵尸对象），并重新测试场景，特别是任何导致CoreLocation事件。
You've had the system send a message to a bad memory location where an object should have been. So my suggestion is to enable zombie detection (Edit Scheme, then select the Diagnostics Tab, tick enable zombie objects) and re-do your test scenarios in particular anything that causes CoreLocation events.
然后当核心位置发送消息到一个释放的对象，你会知道什么对象最初被释放（因为它被人为地保持活着由这个调试设置为僵尸对象）。
Then when core location sends a message to a released object, you will know what the object was originally that got released (because it is artificially kept alive by this debug setting as a zombie object).
这篇关于iOS崩溃核心位置CFBasicHashCreateCopy？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！