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.
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 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.
My app is working perfectly fine in development but switching to production / AdHoc release it crashes on the transition to the third UIViewController of my application flow.
Between the build there shouldn't be any difference. I have retrieved the log from the Devices window:
Exception Type: EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0000000000000001, 0x00000001000d49ac
Triggered by Thread: 0
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 MYAPP 0x00000001000d49ac 0x100010000 + 805292
1 UIKit 0x00000001868a8954 -[UIViewController loadViewIfRequired] + 688
2 UIKit 0x00000001868a8664 -[UIViewController view] + 28
3 UIKit 0x0000000186f9c1cc -[_UIFullscreenPresentationController _setPresentedViewController:] + 72
4 UIKit 0x0000000186ba378c -[UIPresentationController initWithPresentedViewController:presentingViewController:] + 116
5 UIKit 0x0000000186bbeb4c -[UIViewController _presentViewController:withAnimationController:completion:] + 1968
6 UIKit 0x0000000186bc0f64 __62-[UIViewController presentViewController:animated:completion:]_block_invoke + 116
7 UIKit 0x0000000186995c48 -[UIViewController presentViewController:animated:completion:] + 212
8 MYAPP 0x0000000100090dcc 0x100010000 + 527820
9 MYAPP 0x0000000100090bd0 0x100010000 + 527312
10 PromiseKit 0x000000010032a9f4 0x1002e8000 + 272884
11 PromiseKit 0x00000001002ee820 0x1002e8000 + 26656
12 libdispatch.dylib 0x00000001936c1990 _dispatch_call_block_and_release + 20
13 libdispatch.dylib 0x00000001936c1950 _dispatch_client_callout + 12
14 libdispatch.dylib 0x00000001936c6208 _dispatch_main_queue_callback_4CF + 1604
15 CoreFoundation 0x00000001820522e8 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 8
16 CoreFoundation 0x0000000182050390 __CFRunLoopRun + 1488
17 CoreFoundation 0x0000000181f7d1f0 CFRunLoopRunSpecific + 392
18 GraphicsServices 0x000000018b39f6f8 GSEventRunModal + 164
19 UIKit 0x000000018690e108 UIApplicationMain + 1484
20 MYAPP 0x00000001000be820 0x100010000 + 714784
21 libdyld.dylib 0x00000001936eea04 start + 0
What is bugging me:
There is a clear inconsistency between the environments I am working on.
The calls from MYAPP doesn't seem to be linked to any component / method call. I'm working with Swift maybe it does cause problem to resolve symbols. Which could make sense since PromiseKit calls are also unresolved.
I have no idea about how to debug this, not even about how to put log everywhere (because I wouldn't know how to get them).
Any help is welcome!
In Build settings, try changing Swift compiler -> Optimization Level -> Release to None. There's still a bug where sometimes the compiler messes up closures when optimizations are on. Maybe that's what's happening to you.
This is the crash report I received from crashlytics and I don't have the slightest clue on what it means or what to do about this. Any tips or suggestions will be appreciated.
Thread : Crashed: NSOperationQueue Serial Queue
0 libsystem_platform.dylib 0x3baef4da _platform_memmove$VARIANT$Swift + 185
1 ??? 0x0000000c
2 DataDetectorsCore 0x350b26bb DDTokenCacheGetItemAtIndexCreateIfNeeded + 90
3 DataDetectorsCore 0x350b2635 DDTokenCacheGetTokensAtPosition + 1084
4 DataDetectorsCore 0x350ae41d _DDScannerHandleState + 472
5 DataDetectorsCore 0x350aea71 _DDScannerHandleState + 2092
6 DataDetectorsCore 0x350addf1 DDScannerScanQuery + 328
7 DataDetectorsUI 0x350c8f7d -[DDOperation main] + 288
8 Foundation 0x31664aa5 -[__NSOperationInternal _start:] + 772
9 Foundation 0x3170896d __NSOQSchedule_f + 60
10 libdispatch.dylib 0x3b9c5e7b _dispatch_queue_drain + 374
11 libdispatch.dylib 0x3b9c2f93 _dispatch_queue_invoke + 42
12 libdispatch.dylib 0x3b9c6745 _dispatch_root_queue_drain + 76
13 libdispatch.dylib 0x3b9c69c5 _dispatch_worker_thread2 + 56
14 libsystem_pthread.dylib 0x3baf0dff _pthread_wqthread + 298
Do you have any part of your app where the user clicks on a URL or specifies a URL which is then handled by your app, or by the system on behalf of your app. The subsystem that does this is DataDetectorsCore.
If you have code around that area, it would be a good idea to add log messages, assert checks, validation, and unit test code.
It might be that you are receiving maliciously crafted URLs; here is an example but for the Mac platform: http://nakedsecurity.sophos.com/2013/02/06/anatomy-of-a-bug-how-mac-os-x-chokes-if-you-type-file/
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