I have some code that wraps an ALAsset object that is retrieved from enumerating the assets in an ALAssetLibrary. I'm getting reports of users encountering crashes with the part of the wrapper object that asks the ALAsset it contains for metadata.
The code that crashes is in this wrapper class and it simply asks for its ALAsset's metadata like so:
[[myAlAsset defaultRepresentation] metadata];
Here is a partial stack trace that is representative of the crashes I'm seeing:
0
CoreFoundation CFDataGetBytePtr + 5
1
PhotoLibraryServices __46-[PLManagedAsset adjustmentsXMPRepresentation]_block_invoke + 228
2
PhotoLibraryServices __46-[PLManagedAsset adjustmentsXMPRepresentation]_block_invoke + 228
3
CoreData developerSubmittedBlockToNSManagedObjectContextPerform + 88
4
CoreData -[NSManagedObjectContext performBlockAndWait:] + 114
5
PhotoLibraryServices -[PLManagedAsset adjustmentsXMPRepresentation] + 226
6
AssetsLibrary __33-[ALAssetRepresentation metadata]_block_invoke + 24
7
AssetsLibrary __53-[ALAssetRepresentationPrivate _performBlockAndWait:]_block_invoke + 68
8
CoreData developerSubmittedBlockToNSManagedObjectContextPerform + 88
9
libdispatch.dylib _dispatch_client_callout + 22
10
libdispatch.dylib _dispatch_barrier_sync_f_invoke + 26
11
CoreData -[NSManagedObjectContext performBlockAndWait:] + 106
12
AssetsLibrary -[ALAssetsLibrary _performBlockAndWait:] + 134
13
AssetsLibrary -[ALAssetRepresentationPrivate _performBlockAndWait:] + 176
14
AssetsLibrary -[ALAssetRepresentation metadata] + 464
Does anyone have ideas on what may be going on? The AlAssetLibrary that underlies these assets is saved with a static reference, so it should not be getting cleaned up in memory and so I wouldn't expect the ALAsset to have been invalidated. This issue seems to have started specifically with iOS 7 being released.
The crash itself is EXC_BAD_ACCESS with KERN_INVALID_ADDRESS at 0x0.
This may have caused because of buffer overflows. Pls check the link of apple website which shows the buffer overflow crash report same as you have. Hope this may help you.
https://developer.apple.com/library/ios/documentation/Security/Conceptual/SecureCodingGuide/Articles/BufferOverflows.html#//apple_ref/doc/uid/TP40002577-SW1
Related
My application crashed again, this time exporting the device crash log as follows (mind articles 11 and 12):
I tried to symbolic it, but I didn't know how to get the dSYM files from afnetworking from the project.
Thread 8 name: Dispatch queue: NSOperationQueue 0x2803df960 (QOS: UNSPECIFIED)
Thread 8 Crashed:
0 libsystem_malloc.dylib 0x0000000197cccda8 nanov2_allocate_from_block$VARIANT$armv81 + 528
1 libsystem_malloc.dylib 0x0000000197cccda8 nanov2_allocate_from_block$VARIANT$armv81 + 528
2 libsystem_malloc.dylib 0x0000000197ccc040 nanov2_allocate$VARIANT$armv81 + 140
3 libsystem_malloc.dylib 0x0000000197ccbf64 nanov2_malloc$VARIANT$armv81 + 60
4 libsystem_malloc.dylib 0x0000000197cd99a0 malloc_zone_malloc + 156
5 CoreFoundation 0x000000019808e160 _CFRuntimeCreateInstance + 324
6 CoreFoundation 0x000000019802b970 __CFArrayInit + 224
7 Foundation 0x0000000198b75470 NSKVOCopyPendingNotificationStack + 152
8 Foundation 0x0000000198b720f8 NSKeyValueWillChangeWithPerThreadPendingNotifications.llvm.16432713543580414412 + 364
9 Foundation 0x0000000198ae8ad4 -[NSProgress _setValueForKeys:settingBlock:] + 272
10 Foundation 0x0000000198aeb9dc -[NSProgress setCompletedUnitCount:] + 132
11 AFNetworking 0x00000001051c965c 0x10519c000 + 185948
12 AFNetworking 0x00000001051d1a18 0x10519c000 + 219672
13 CFNetwork 0x0000000198898b94 __67-[NSURLSession delegate_dataTask:didReceiveData:completionHandler:]_block_invoke.303 + 36
14 Foundation 0x0000000198b8c8bc __NSBLOCKOPERATION_IS_CALLING_OUT_TO_A_BLOCK__ + 16
15 Foundation 0x0000000198a94ab8 -[NSBlockOperation main] + 72
16 Foundation 0x0000000198a93f8c -[__NSOperationInternal _start:] + 740
17 Foundation 0x0000000198b8e790 __NSOQSchedule_f + 272
18 libdispatch.dylib 0x0000000197b356c8 _dispatch_call_block_and_release + 24
19 libdispatch.dylib 0x0000000197b36484 _dispatch_client_callout + 16
20 libdispatch.dylib 0x0000000197b0ce04 _dispatch_continuation_pop$VARIANT$armv81 + 404
21 libdispatch.dylib 0x0000000197b0c4e8 _dispatch_async_redirect_invoke + 592
22 libdispatch.dylib 0x0000000197b18aec _dispatch_root_queue_drain + 344
23 libdispatch.dylib 0x0000000197b1934c _dispatch_worker_thread2 + 116
24 libsystem_pthread.dylib 0x0000000197d1917c _pthread_wqthread + 472
25 libsystem_pthread.dylib 0x0000000197d1bcec start_wqthread + 4
If it's not afnetworking fault, can anyone see why? Please help me.
So, your app has crashed pretty deep in Apple's code, and specifically inside libsystem_malloc. While I cannot be certain, my guess is you're looking at an example of heap corruption.
Dynamically allocated memory is shared by your entire process, and everything in it. That means that any code could potentially overwrite and/or otherwise corrupt structures used by other, even unrelated, parts of the system. In this case, it looks like something has messed up the internal book-keeping structures used by malloc. I would guess this happens by overrunning a buffer and writing outside of an allocated piece of memory's bounds.
What I can say with high confidence is that this particular report does not give you enough information to blame AFNetworking. It just happened to be unlucky enough to be running when that corrupt memory was accessed. Even one memory corruption bug can cause a variety of different crashes. Because of that, it's not really possible to reason about the cause of any one particular crash.
The good news is this kind of thing is very common. Bad news is it can be very hard to track down. What I'd recommend trying is to make use of the memory debugging tools that Apple provides. Things like NSZombies (via instruments), guardmalloc, and malloc scribble. Your best bet is to just fix all the memory-related bugs you can find.
I'm getting this inconsistent, hard to reproduce crash in RestKit. The crash occurs on NSManagedObjectContext::save(), inside RKManagedObjectRequestOperation::saveContextToPersistentStore:failedContext:error (here's the exact line of code).
This crash happened to over a dozen different users in our production environment but I've personally been unable to reproduce it. I have no clue as to what might be causing this crash. My only clue is _forceRegisterLostFault which may suggest faulted/deleted objects are involved.
Background: RKManagedObjectRequestOperation::saveContextToPersistentStore:failedContext:error is invoked every time RestKit mapping is completed following a network request.
Has anyone encountered this particular EXC_BREAKPOINT in CoreData before?
Any suggestions on how to tackle this?
Stack trace:
Crashed: NSManagedObjectContext 0x1741cf5a0
0 CoreData 0x18add7c7c -[NSManagedObjectContext(_NSInternalAdditions) _forceRegisterLostFault:] + 160
1 CoreData 0x18ad5c8b0 -[NSManagedObjectContext(_NSInternalAdditions) _validateObjects:forOperation:error:exhaustive:forSave:] + 2884
2 CoreData 0x18ad5bcf8 -[NSManagedObjectContext(_NSInternalAdditions) _validateChangesForSave:] + 364
3 CoreData 0x18ad5b94c -[NSManagedObjectContext(_NSInternalChangeProcessing) _prepareForPushChanges:] + 196
4 CoreData 0x18ad51ec4 -[NSManagedObjectContext save:] + 544
5 RestKit 0x1013214b8 __84-[RKManagedObjectRequestOperation saveContextToPersistentStore:failedContext:error:]_block_invoke (RKManagedObjectRequestOperation.m:800)
6 CoreData 0x18add5b70 developerSubmittedBlockToNSManagedObjectContextPerform + 152
7 libdispatch.dylib 0x1878e91c0 _dispatch_client_callout + 16
8 libdispatch.dylib 0x1878f6860 _dispatch_barrier_sync_f_invoke + 84
9 CoreData 0x18add5a80 -[NSManagedObjectContext performBlockAndWait:] + 308
10 RestKit 0x1013212b8 -[RKManagedObjectRequestOperation saveContextToPersistentStore:failedContext:error:] (RKManagedObjectRequestOperation.m:808)
11 RestKit 0x1013216d0 -[RKManagedObjectRequestOperation saveContext:error:] (RKManagedObjectRequestOperation.m:831)
12 RestKit 0x101321f54 -[RKManagedObjectRequestOperation saveContext:] (RKManagedObjectRequestOperation.m:874)
13 RestKit 0x10131f654 __79-[RKManagedObjectRequestOperation performMappingOnResponseWithCompletionBlock:]_block_invoke.350 (RKManagedObjectRequestOperation.m:660)
14 RestKit 0x1013534a0 -[RKResponseMapperOperation willFinish] (RKResponseMapperOperation.m:323)
15 RestKit 0x101353ac4 -[RKResponseMapperOperation main] (RKResponseMapperOperation.m:411)
16 Foundation 0x1894578c4 -[__NSOperationInternal _start:] + 620
17 Foundation 0x189524b00 __NSOQSchedule_f + 228
18 libdispatch.dylib 0x1878e91c0 _dispatch_client_callout + 16
19 libdispatch.dylib 0x1878f7444 _dispatch_queue_serial_drain + 928
20 libdispatch.dylib 0x1878ec9a8 _dispatch_queue_invoke + 652
21 libdispatch.dylib 0x1878f938c _dispatch_root_queue_drain + 572
22 libdispatch.dylib 0x1878f90ec _dispatch_worker_thread3 + 124
23 libsystem_pthread.dylib 0x187af22b8 _pthread_wqthread + 1288
24 libsystem_pthread.dylib 0x187af1da4 start_wqthread + 4
There are a few different causes I've seen for this error.
Accessing Managed Objects and/or Contexts on the wrong thread. Use Core Data Concurrency Debugging to validate that you're always using the right thread, with the -com.apple.CoreData.ConcurrencyDebug 1 argument.
Corrupted Sqlite file - does your app include an out-of-box Core Data store? Make sure all the metadata in it is correct.
Overriding the default accessors in your Core Data Managed Objects. Be careful if you have objects with primitive (int or float instead of NSNumber) properties.
I am having the following crash (0.05% crash rate, so I have yet to reproduce it):
0 libdispatch.dylib 0x208b2028 _dispatch_semaphore_signal_slow + 174
! 1 MyProject 0x00253f39 __64-[CRNSURLSessionTaskProxy wrapDataCompletionHandler:forSession:]_block_invoke + 422
2 CFNetwork 0x2120796d __75-[__NSURLSessionLocal taskForClass:request:uploadFile:bodyData:completion:]_block_invoke + 14
3 CFNetwork 0x21216ef7 __49-[__NSCFLocalSessionTask _task_onqueue_didFinish]_block_invoke + 276
4 Foundation 0x2150a52d __NSBLOCKOPERATION_IS_CALLING_OUT_TO_A_BLOCK__ + 6
5 Foundation 0x2146beff -[NSBlockOperation main] + 144
6 Foundation 0x2145e2ef -[__NSOperationInternal _start:] + 772
7 Foundation 0x2150c7ed __NSOQSchedule_f + 190
8 libdispatch.dylib 0x208adf97 _dispatch_queue_drain + 1760
9 libdispatch.dylib 0x208a6f2f _dispatch_queue_invoke + 280
10 libdispatch.dylib 0x208af325 _dispatch_root_queue_drain + 398
11 libdispatch.dylib 0x208af193 _dispatch_worker_thread3 + 92
12 libsystem_pthread.dylib 0x20a3ce0d _pthread_wqthread + 1022
13 libsystem_pthread.dylib 0x20a3c9fc start_wqthread + 6
The crashes only appears on iOS9, none whatsoever on iOS8, but this could just be a coincidence. I am also seeing this via Crittercism breadcrumbs:
I am also using Background Fetches which do hit the network layer.
Any idea why this is happing?
This looks to me like a bug with Crittercism. The class CRNSURLSessionTaskProxy is a Crittercism class (see below), so it's crashing in their code, which is corroborated by the errors in the Crittercism breadcrumbs.
The only Google hit (other than this question) for the class name is this one. If you look at the other classes in that dump that start with CR, you will see CRBreadcrumbs and CRCrash.
Also here's a dump of the Crittercism framework in the Hopper disassembler:
Pretty conclusive I would say.
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
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
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?
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.
I'm having trouble reproducing the crash detailed below (got it from crash analytics/tracking). There always also appears to be another suspect looking thread running alongside the crashed thread at the same time on every instance of the crash reported:
Crashed Thread
0 CoreFoundation 0x2f9074be CFGetTypeID + 6
1 CoreFoundation 0x2f91e47b _flattenPlist + 47
2 CoreFoundation 0x2f91e57f _flattenPlist + 307
3 CoreFoundation 0x2f98257b __CFBinaryPlistWrite + 131
4 CoreFoundation 0x2f91e321 CFPropertyListWrite + 245
5 CoreFoundation 0x2f92e731 CFPropertyListWriteToStream + 145
6 CoreFoundation 0x2f92c39d _CFXPreferencesWritePlist + 269
7 CoreFoundation 0x2f92c28b -[CFXPreferencesPropertyListSourceSynchronizer writePlistToDisk] + 131
8 CoreFoundation 0x2f929aef -[CFXPreferencesPropertyListSourceSynchronizer synchronizeAlreadyFlocked] + 487
9 CoreFoundation 0x2f929905 -[CFXPreferencesPropertyListSourceSynchronizer synchronize] + 21
10 CoreFoundation 0x2f929405 __79-[CFXPreferencesPropertyListSource synchronizeInBackgroundWithCompletionBlock:]_block_invoke + 101
11 libdispatch.dylib 0x3a656d53 _dispatch_call_block_and_release + 11
12 libdispatch.dylib 0x3a65bcbd _dispatch_queue_drain + 489
13 libdispatch.dylib 0x3a658c6f _dispatch_queue_invoke + 43
14 libdispatch.dylib 0x3a65c5f1 _dispatch_root_queue_drain + 77
15 libdispatch.dylib 0x3a65c8dd _dispatch_worker_thread2 + 57
16 libsystem_pthread.dylib 0x3a787c17 _pthread_wqthread + 299
17 libsystem_pthread.dylib 0x3a787adc start_wqthread + 8
Other suspect thread (that always runs at the same time and looks like it's related):
0 libsystem_kernel.dylib 0x3a70faa0 semaphore_wait_trap + 8
1 libdispatch.dylib 0x3a65b513 _dispatch_barrier_sync_f_slow + 139
2 CoreFoundation 0x2f94424d CFPreferencesAppSynchronize + 265
3 Foundation 0x3032e91d -[NSUserDefaults(NSUserDefaults) synchronize] + 25
4 MailOnline 0x00280897 ADBLifecycleStart + 2495
5 CoreFoundation 0x2f998f41 _CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ + 13
6 CoreFoundation 0x2f90cda9 _CFXNotificationPost + 1721
7 Foundation 0x302f7cc5 -[NSNotificationCenter postNotificationName:object:userInfo:] + 73
8 UIKit 0x3246747f -[UIApplication _sendWillEnterForegroundCallbacks] + 155
9 UIKit 0x3240c88b -[UIApplication _handleApplicationResumeEvent:] + 927
10 UIKit 0x3220b613 -[UIApplication handleEvent:withNewEvent:] + 1883
11 UIKit 0x3220adf9 -[UIApplication sendEvent:] + 73
12 UIKit 0x3226f405 _UIApplicationHandleEvent + 617
13 GraphicsServices 0x34878b55 _PurpleEventCallback + 609
14 GraphicsServices 0x3487873f PurpleEventCallback + 35
15 CoreFoundation 0x2f9a1847 _CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ + 35
16 CoreFoundation 0x2f9a17e3 __CFRunLoopDoSource1 + 347
17 CoreFoundation 0x2f99ffaf __CFRunLoopRun + 1407
18 CoreFoundation 0x2f90a769 CFRunLoopRunSpecific + 525
19 CoreFoundation 0x2f90a54b CFRunLoopRunInMode + 107
20 GraphicsServices 0x348776d3 GSEventRunModal + 139
21 UIKit 0x32269891 UIApplicationMain + 1137
22 MailOnline 0x000cd18b main (main.m:16)
23 libdyld.dylib 0x3a66bab7 start + 3
When debugging the running program it appears that the Adobe Mobile SDK we use for tracking listens to the return to foreground event fired by the OS and then calls synchronize on the NSUserDefaults (see Other suspect thread). The synchronize then breaks off into another thread (the crashed thread) but then it crashes for some reason when trying to write to a plist file.
I cannot reproduce the crash. We are using v4.0 of the Adobe Mobile Library iOS SDK so if anyone else has had similar crashes with these SDKs then please help!? Or if anyone has any suggestions for steps to make this crash more likely to happen (e.g. I've tried writing to plist constantly when the SDK runs to see if it was a threading issue but with no luck) then please advise...
NOTE: This issue is still happening on newer devices running iOS 7 but still does not ever occur on devices running iOS 8.0 or 8.1.
This issue is due to a race condition inside of NSUserDefaults itself. The following code snippet will reproduce the issue in an isolated scenario(You'll need to let this code run for 15-30 seconds to expose the issue):
dispatch_async(dispatch_get_main_queue(), ^{
while(true) {
for(int i = 0; i < 20000; i++) {
[[NSUserDefaults standardUserDefaults] setObject: #"value" forKey: [NSString stringWithFormat: #"blah%d",i]];
}
for(int i = 0; i < 20000; i++) {
[[NSUserDefaults standardUserDefaults] removeObjectForKey: [NSString stringWithFormat: #"blah%d",i]];
}
}
});
Other people have reported this issue, clearest example of this being this post on the apple developer forums(registration required).
My recommendation would be to check your code for any significant read/write cycles into NSUserDefaults. If you need to do a massive amount of changes or updates to data, you probably want to roll your own persistence layer instead of NSUserDefaults until this issue is resolved by Apple.
The ADBLifecycleStart method is a red-herring in this scenario. This code runs on it's own queue, and will probably be living (or at least caught by a full thread dump) most of the time. The ADBLifeCycleStart method makes a worst case total of 13 writes to NSUserDefaults, followed by a synchronize.
Note: At WWDC this year, Apple Engineers confirmed that NSUserDefaults got a total rewrite. After some testing, this issue appears to have been resolved and is no longer reproducible running iOS 8.
Henry,
On launch, the sdk updates some items stored in NSUserDefaults. After those items are updated, NSUserDefaults attempts to synchronize which updates the NSUserDefaults plist. It looks like the application is crashing at the point when the device is attempting to update that plist. After some investigation it seems that this can happen for a couple different reasons. 1) If zombie mode is turned on (causing memory to never be freed) and your app reaches 4GB per-process, 2) The nsuserdefaults plist has become corrupt.
-Hunter