无法追踪 [NSData getBytes:length:] 崩溃 [英] Cannot track down [NSData getBytes:length:] crash

问题描述

我在 Foundation 的 -[NSData(NSData) getBytes:length:] 方法中遇到了一个奇怪的 EXC_BAD_ACCESS 崩溃.它经常发生，但我无法从堆栈跟踪中获取任何有意义的信息.我的代码中没有对 getBytes:length: 的调用，除了开源库(一个在 SDWebImage 中，一个在 SocketRocket 中)，但似乎他们并没有导致崩溃.

I got a strange EXC_BAD_ACCESS crash inside Foundation's -[NSData(NSData) getBytes:length:] method. It happens quite often, but I cannot get any meaningful information out of stack trace. There are no calls to getBytes:length: inside my code, except for open-source libraries (one in SDWebImage and one in SocketRocket), but it doesn't seem like they're causing the crash.

唯一的提示是崩溃发生在 com.apple.CFNetwork.addPersistCacheToStorageDaemon 线程内，但我不知道它是怎么回事.有人可以帮忙吗?

The only hint is that crash happens inside com.apple.CFNetwork.addPersistCacheToStorageDaemon thread, but I have no idea what is it about. Can someone help?

来自 Crashlytics 的堆栈跟踪:

Stacktrace from Crashlytics:

Thread : Crashed: com.apple.CFNetwork.addPersistCacheToStorageDaemon
0  libsystem_platform.dylib       0x3044a208 _platform_memmove$VARIANT$CortexA9 + 160
1  Foundation                     0x22df9167 -[NSData(NSData) getBytes:length:] + 118
2  Foundation                     0x22df9167 -[NSData(NSData) getBytes:length:] + 118
3  Foundation                     0x22e21a1b -[NSData(NSData) replacementObjectForCoder:] + 134
4  Foundation                     0x22dc2aff -[NSXPCEncoder _replaceObject:] + 90
5  Foundation                     0x22e240dd -[NSXPCEncoder _encodeArrayOfObjects:forKey:] + 192
6  Foundation                     0x22e212ff -[NSDictionary(NSDictionary) encodeWithCoder:] + 922
7  Foundation                     0x22dc32c9 -[NSXPCEncoder _encodeObject:] + 604
8  Foundation                     0x22dc379d encodeInvocationArguments + 460
9  Foundation                     0x22dc3455 -[NSXPCEncoder encodeInvocation:] + 360
10 Foundation                     0x22dc32c9 -[NSXPCEncoder _encodeObject:] + 604
11 Foundation                     0x22dc2335 -[NSXPCConnection _sendInvocation:proxyNumber:remoteInterface:withErrorHandler:timeout:userInfo:] + 1860
12 Foundation                     0x22dd2823 -[NSXPCConnection _sendInvocation:proxyNumber:remoteInterface:withErrorHandler:] + 58
13 Foundation                     0x22dd27db -[_NSXPCDistantObjectWithError forwardInvocation:] + 114
14 CoreFoundation                 0x2217e831 ___forwarding___ + 352
15 CoreFoundation                 0x220afb88 _CF_forwarding_prep_0 + 24
16 CFNetwork                      0x21c52ac9 -[NSURLStorage_CacheClient addCachedResponseWithDictionary:key:] + 120
17 CFNetwork                      0x21c21e29 ___ZN12__CFURLCache23CreateAndStoreCacheNodeEP16__CFURLCacheNodePK20_CFCachedURLResponsePK10__CFStringPK13_CFURLRequestPKvbRb_block_invoke + 1576
18 libdispatch.dylib              0x302cf423 _dispatch_call_block_and_release + 10
19 libdispatch.dylib              0x302d95d9 _dispatch_queue_drain$VARIANT$mp + 948
20 libdispatch.dylib              0x302d90a9 _dispatch_queue_invoke$VARIANT$mp + 84
21 libdispatch.dylib              0x302db0d3 _dispatch_root_queue_drain + 330
22 libdispatch.dylib              0x302dc1fb _dispatch_worker_thread3 + 106
23 libsystem_pthread.dylib        0x3044ce25 _pthread_wqthread + 668

还有一个(发生频率较低):

And another one (happens less often):

Thread : Crashed: com.apple.CFNetwork.addPersistCacheToStorageDaemon
0  libsystem_platform.dylib       0x000000019344d300 _platform_memmove + 176
1  Foundation                     0x0000000182dfce18 -[NSData(NSData) getBytes:length:] + 172
2  Foundation                     0x0000000182dfce18 -[NSData(NSData) getBytes:length:] + 172
3  Foundation                     0x0000000182e2ae3c -[NSData(NSData) replacementObjectForCoder:] + 160
4  Foundation                     0x0000000182dbd320 -[NSXPCEncoder _replaceObject:] + 120
5  Foundation                     0x0000000182e2dac8 -[NSXPCEncoder _encodeArrayOfObjects:forKey:] + 256
6  Foundation                     0x0000000182e2a544 -[NSDictionary(NSDictionary) encodeWithCoder:] + 1016
7  Foundation                     0x0000000182dbdd10 -[NSXPCEncoder _encodeObject:] + 716
8  Foundation                     0x0000000182dbe2e8 encodeInvocationArguments + 508
9  Foundation                     0x0000000182dbdee4 -[NSXPCEncoder encodeInvocation:] + 412
10 Foundation                     0x0000000182dbdd10 -[NSXPCEncoder _encodeObject:] + 716
11 Foundation                     0x0000000182dbcb0c -[NSXPCConnection _sendInvocation:proxyNumber:remoteInterface:withErrorHandler:timeout:userInfo:] + 2196
12 CoreFoundation                 0x0000000181fde230 ___forwarding___ + 440
13 CoreFoundation                 0x0000000181ee2b6c _CF_forwarding_prep_0 + 92
14 CFNetwork                      0x000000018199c908 ___ZN12__CFURLCache23CreateAndStoreCacheNodeEP16__CFURLCacheNodePK20_CFCachedURLResponsePK10__CFStringPK13_CFURLRequestPKvbRb_block_invoke + 1976
15 libdispatch.dylib              0x00000001932793ac _dispatch_call_block_and_release + 24
16 libdispatch.dylib              0x000000019327936c _dispatch_client_callout + 16
17 libdispatch.dylib              0x00000001932834c0 _dispatch_queue_drain + 1216
18 libdispatch.dylib              0x000000019327c474 _dispatch_queue_invoke + 132
19 libdispatch.dylib              0x0000000193285224 _dispatch_root_queue_drain + 664
20 libdispatch.dylib              0x000000019328675c _dispatch_worker_thread3 + 108
21 libsystem_pthread.dylib        0x00000001934552e4 _pthread_wqthread + 816

推荐答案

随着 iOS 8 的引入，也发生了一些意想不到的错误，我们也必须牢记这一点.

With the introduction of iOS 8 there are some unexpected bug occurrance also happening we've to keep that in mind as well.

像 MIT Mobile、Mile point 这样的应用程序也遇到了像你这样的问题，虽然目前还没有广泛传播.

Apps like MIT Mobile,Mile point also suffers from the issue like yours,this is not wide spread though as of now.

这里是 MIT & 的错误链接;MilePoint.

Here are the bug links for MIT & MilePoint.

com.apple.CFNetwork.addPersistCacheToStorageDaemon

CFNetwork 是较低级别的 C API，它由更高级别的类(如 NSURLConnection)包装.

CFNetwork is lower level C API and it is wrapped by higher level class like NSURLConnection.

所以崩溃发生在网络操作期间

EXC_BAD_ACCESS

这意味着消息被发送到一个没有类实例来执行它的内存地址.因此导致访问不正确"

It means that message was sent to an memory address where there’s no instance of a class to execute it. Thus results "bad access"

什么时候会发生?

1. 对象未初始化
2. 一个对象已经被释放了
3. 其他不太可能发生的事情

我们该如何解决这个问题?

• 您可以通过在 xcode 中启用 NSZombie 来捕获一些错误(编号 2)

• You can catch some of the bugs(number 2) by Enabling NSZombie in xcode

启用 NSZombie:

启用此功能后，每个已释放对象的位置都会保留一个虚拟对象(僵尸)，从而允许调试已释放的对象.非常容易启用:

When this feature is enabled, a dummy object (a zombie) is kept on the place of every released object, thus allowing to debug objects which were released already. Very easy to enable:

1. 在 XCode 的可执行文件"中双击你的可执行文件
2. 在要在环境中设置的变量"中打开参数"选项卡(这是底部的列表，请注意您编辑的是哪个)
3. 点击+"按钮，变量名输入NSZombieEnabled"，值YES"

现在，您不必想知道发生了什么以及究竟是哪个对象产生了问题，而是确切地看到哪个类是麻烦制造者，并且您会很快调试它.

Now instead of wondering what’s going on and which exact object produced the problem, you’ll see exactly which class is the trouble maker, and you’ll debug it quite fast.

注意:当您将应用程序提交到 App Store 时，不要让僵尸程序处于启用状态.此外，如果您真的不需要它们，最好禁用它们.

Note: Do not leave the zombies enabled, when you submit your app to the App store. Also, it’s a good practice to disable them if you don’t really need them.

• 如果您使用第三方库，请将其更新到最新版本

注意:

我的建议是永远不要使用第三方框架，除非这是不可避免的，因为库本身有时会出现开发人员无法控制的错误，有时库会更新到当前的 SDK.您可以找到更多关于它的信息 这里

My suggestion is never use third party framework unless its unavoidable because the library itself will have bugs sometimes which is out of developer control and sometimes library would be updated late to current SDK.You can find more about it here

希望对你有帮助

这篇关于无法追踪 [NSData getBytes:length:] 崩溃的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！