Cannot track down [NSData getBytes:length:] crash

问题

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.

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?

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

回答1:

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

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

Here are the bug links for MIT & MilePoint.

com.apple.CFNetwork.addPersistCacheToStorageDaemon

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

so the crash occurs during a network operation

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”

When will it happen?

An object is not initialized
An object is already released
Something else that is not very likely to happen

How can we solve this problem ?

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

Enabling 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:

Double click your executable in the “Executables” in XCode
Open “Arguments” tab In “Variables to be set in the environment” (that’s the list at the bottom, be careful which one you edit)
click the “+” button and for name of the variable enter “NSZombieEnabled” and for value “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.

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.

If you are using third party libraries kindly update it to the latest

Note:

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

Hope this helps

回答2:

My guess is that you have

some __unsafe_unretained (that is unavoidable for setter Path [NSInvocation setArgument:atIndex:])
or an issue like this one
or (more likely) a deadlock during a performBlockAndWait (since I've seen a connection/timeout in the stack)

A couple of related suggestions:

1) NSManagedObject, NSManagedObjectContext, and NSPersistentStoreCoordinator (given the crash at addPersistCacheToStorageDaemon) aren't thread safe:

consider this if you are using performBlockAndWait to send messages to your NSManagedObjectContext (more here and here) or nested MOC.

2) CFNetwork is a lower-level class that is wrapped by the NSURLConnection:

so not using NSURL ? avoiding addObserver:self forKeyPath (KVO) to a property of a NSURL Session?

回答3:

The issue could actually be from SDWebImage quote from this site:

http://webcache.googleusercontent.com/search?q=cache:BCShJT0ZrvoJ:quabr.com/15786084/uicollectionview-bad-acces-on-uicollectionviewdata-setlayoutattributesatglo+&cd=7&hl=fr&ct=clnk&gl=jp

Now if you are using AFNetworking to set the image directly from the URL using the AFNetworking category you may want to use the alternate method so you can intervene and resize the image. The code below will do that.

NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:imageURL];
[request addValue:@"image/*" forHTTPHeaderField:@"Accept"];

[imageView setImageWithURLRequest:request placeholderImage:nil success:^(NSURLRequest *request, NSHTTPURLResponse *response, UIImage *image) {
    // resize image
    // set image on imageView
} failure:^(NSURLRequest *request, NSHTTPURLResponse *response, NSError *error) {
    // handle error
}];

I would also check this page for related crashes:

https://github.com/rs/SDWebImage/issues?q=is%3Aopen+is%3Aissue+label%3Acrash

Check if you are using the latest version of SDWebImage, otherwise you might have to check out older issues.

来源：https://stackoverflow.com/questions/28949799/cannot-track-down-nsdata-getbyteslength-crash

标签

ios