I have received a Crashlytics crash report for the above mentioned issue.
It seems that the issue is related to CFNetwork, however, I do not call that directly. However, I do use the reachability class which seems to reference it.
Can anyone help shed any light on where I should start to look for this?
I am enclosing the relevant logs.
Thread : Crashed: com.apple.root.default-priority
0 libsystem_platform.dylib 0x3accd810 _os_lock_corruption_abort + 18446744073709552000
1 libsystem_platform.dylib 0x3accd80f _OSSpinLockLockSlow$VARIANT$mp + 102
2 CFNetwork 0x2fec857b CoreStreamBase::_streamSetEventAndScheduleDelivery(unsigned long, unsigned char) + 30
3 CFNetwork 0x2fec6f85 CoreStreamBase::_streamInterface_Open() + 108
4 CFNetwork 0x2feeb56b HTTPReadStream::startRequest(CFStreamError*) + 858
5 CFNetwork 0x2feeae95 HTTPReadStream::_streamImpl_Open(CFStreamError*, unsigned char*) + 416
6 CFNetwork 0x2ff23933 non-virtual thunk to HTTPReadStream::_streamImpl_Open(CFStreamError*, unsigned char*) + 10
7 CFNetwork 0x2fec6f45 CoreStreamBase::_streamInterface_Open() + 44
8 CFNetwork 0x2ff12c39 ___ZL24executionContextSchedulePvP11__CFRunLoopPK10__CFString_block_invoke + 448
9 libdispatch.dylib 0x3ab8ed7b _dispatch_call_block_and_release + 10
10 libdispatch.dylib 0x3ab95da5 _dispatch_root_queue_drain + 220
11 libdispatch.dylib 0x3ab95f8d _dispatch_worker_thread2 + 56
12 libsystem_pthread.dylib 0x3acd0dbf _pthread_wqthread + 298
Thread : com.apple.main-thread
0 libobjc.A.dylib 0x3a6a6b22 objc_msgSend + 1
1 CoreFoundation 0x3020ff33 -[__NSDictionaryM objectForKey:] + 70
2 Foundation 0x30c2a85b -[NSDateFormatter setDateFormat:] + 82
3 AppTest00001 0x00098c73 -[AppDelegate checkSubs] (AppDelegate.m:342)
4 AppTest00001 0x0009785b -[AppDelegate application:didFinishLaunchingWithOptions:] (AppDelegate.m:102)
5 UIKit 0x32ab4cb7 -[UIApplication _handleDelegateCallbacksWithOptions:isSuspended:restoreState:] + 274
6 UIKit 0x32ab4707 -[UIApplication _callInitializationDelegatesForURL:payload:suspended:] + 1390
7 UIKit 0x32aaed13 -[UIApplication _runWithURL:payload:launchOrientation:statusBarStyle:statusBarHidden:] + 714
8 UIKit 0x32a496a7 -[UIApplication handleEvent:withNewEvent:] + 3130
9 UIKit 0x32a489a9 -[UIApplication sendEvent:] + 72
10 UIKit 0x32aae4fd _UIApplicationHandleEvent + 664
11 GraphicsServices 0x34f2870d _PurpleEventCallback + 608
12 GraphicsServices 0x34f282f7 PurpleEventCallback + 34
13 CoreFoundation 0x3029d9e7 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ + 34
14 CoreFoundation 0x3029d983 __CFRunLoopDoSource1 + 346
15 CoreFoundation 0x3029c157 __CFRunLoopRun + 1398
16 CoreFoundation 0x30206ce7 CFRunLoopRunSpecific + 522
17 CoreFoundation 0x30206acb CFRunLoopRunInMode + 106
18 UIKit 0x32aad799 -[UIApplication _run] + 760
19 UIKit 0x32aa8a41 UIApplicationMain + 1136
20 AppTest00001 0x0009cd3f main (main.m:16)
Thread : com.apple.CFURLCACHE_work_queue 0 libsystem_kernel.dylib
0x3ac588fc pread + 20 1 libsqlite3.dylib 0x3a94e5bd sqlite3_snprintf + 8252 2 libsqlite3.dylib 0x3a961b0d sqlite3_finalize + 11428 3 libsqlite3.dylib 0x3a961629 sqlite3_finalize + 10176 4 libsqlite3.dylib 0x3a960f9d sqlite3_finalize + 8500 5 libsqlite3.dylib 0x3a960299 sqlite3_finalize + 5168 6 libsqlite3.dylib 0x3a95d183 sqlite3_exec + 55702 7 libsqlite3.dylib 0x3a95cf99 sqlite3_exec + 55212 8 libsqlite3.dylib 0x3a959c0f sqlite3_exec + 42018 9 libsqlite3.dylib 0x3a953853 sqlite3_exec + 16486 10 libsqlite3.dylib 0x3a950f9d sqlite3_exec + 6064 11 libsqlite3.dylib 0x3a950797 sqlite3_exec + 4010 12 libsqlite3.dylib 0x3a9500fb sqlite3_exec + 2318 13 libsqlite3.dylib 0x3a94fe4d sqlite3_exec + 1632 14 libsqlite3.dylib 0x3a94f927 sqlite3_exec + 314 15 CFNetwork 0x2fecb797 __CFURLCache::OpenDatabase() + 246 16 CFNetwork 0x2ff08edd __CFURLCache::ProcessCacheTasks0(bool) + 448 17 CFNetwork
0x2ff08c21 __CFURLCache::ProcessCacheTasks(bool) + 36 18 CFNetwork
0x2ff08ab7 __CFURLCache::_CFURLCacheTimerCallback0() + 626 19 CFNetwork 0x2ff08839 __CFURLCache::_CFURLCacheTimerCallback(void*) + 32 20 CFNetwork 0x2ff0c339 ___ZN12__CFURLCache29SignalWorkerTaskToPerformWorkEv_block_invoke + 12 21 libdispatch.dylib 0x3ab8ed7b _dispatch_call_block_and_release + 10 22 libdispatch.dylib 0x3ab95297 _dispatch_queue_drain$VARIANT$mp + 374 23 libdispatch.dylib 0x3ab9509b _dispatch_queue_invoke$VARIANT$mp + 42 24 libdispatch.dylib 0x3ab95d15 _dispatch_root_queue_drain + 76 25 libdispatch.dylib
0x3ab95f8d _dispatch_worker_thread2 + 56 26 libsystem_pthread.dylib
0x3acd0dbf _pthread_wqthread + 298
Thread : com.apple.NSURLConnectionLoader (com.apple.root.default-overcommit-priority)
0 libsystem_kernel.dylib 0x3ac69fa8 __psynch_mutexwait + 24
1 libsystem_pthread.dylib 0x3acd0f0f _pthread_mutex_lock + 306
2 CFNetwork 0x2ff12ea7 PACEntryStreamCallback(__CoreReadStream*, unsigned long, void*) + 70
3 CFNetwork 0x2fec8831 CoreReadStreamClient::coreStreamEventsAvailable(unsigned long) + 36
4 CFNetwork 0x2ff6f173 CoreStreamBase::_callClientNow(CoreStreamClient*) + 42
5 CFNetwork 0x2ff6f193 ___ZN14CoreStreamBase34_streamSetEventAndScheduleDeliveryEmh_block_invoke + 22
6 CFNetwork 0x2ff7031f ___ZNK17CoreSchedulingSet13_performAsyncEPKcU13block_pointerFvvE_block_invoke + 18
7 CoreFoundation 0x30206719 CFArrayApplyFunction + 36
8 CFNetwork 0x2fed6c3d RunloopBlockContext::perform() + 164
9 CFNetwork 0x2fed6b0d MultiplexerSource::perform() + 220
10 CFNetwork 0x2fed69a1 MultiplexerSource::_perform(void*) + 48
11 CoreFoundation 0x3029e18b __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 14
12 CoreFoundation 0x3029d65b __CFRunLoopDoSources0 + 206
13 CoreFoundation 0x3029be4f __CFRunLoopRun + 622
14 CoreFoundation 0x30206ce7 CFRunLoopRunSpecific + 522
15 CoreFoundation 0x30206acb CFRunLoopRunInMode + 106
16 Foundation 0x30c40497 +[NSURLConnection(Loader) _resourceLoadLoop:] + 318
17 Foundation 0x30cb5e27 __NSThread__main__ + 1062
18 libsystem_pthread.dylib 0x3acd2c1d _pthread_body + 140
19 libsystem_pthread.dylib 0x3acd2b8f _pthread_start + 102
IIRC, _os_lock_corruption_abort is typically caused by accessing a lock whose data has been overwritten by other data, which (assuming you aren't doing anything that would cause a buffer overflow somewhere) is likely caused by a zombie continuing to receive method calls after it has been fully released and deallocated.
Reachability uses NSURLConnection to determine whether the URL you specified is reachable after the device's connection status changes (e.g. after connecting to a Wi-Fi network or roaming out of cellular range), hence any bugs in NSURLConnection are going to show up with the reachability API, too.
Now I don't know why NSURLConnection has a zombie problem, but I've also noticed it myself, to the tune of several dozen crashes with unique backtraces in random parts of the networking stack, every one of which points to data arriving on sockets after the NSURLConnection object is gone, with the most frequent ones being JavaScriptCore crashes while handling proxy PAC files. This shouldn't be possible, because in addition to NSURLConnection itself retaining itself and its delegate, we're also not releasing any connection objects without canceling them. Yet I'm still seeing the crashes.
In an attempt to work around the bug, I'm adding code to aggressively hold on to our NSURLConnection objects for several times the timeout period before releasing them. Obviously to do that for reachability-related requests, you would have to do it by swizzling the designated initializer for NSURLConnection (which is an option, obviously).
My general advice would be to ignore this unless you see a lot of crashes, because swizzling is a serious pain. With that said, if you're seeing a lot of crashes, it might be worth adopting a similar approach.
Hope that helps.