Crash in CFReadStreamCopyProperty from + [NSURLConnection (Loader) _resourceLoadLoop:]
I see two different variations of this crash inside CFNetwork in our VOIP application:
First appearance:
Thread 4 Crashed: 0 ??? 0x20333434 0x0 + 0 1 CoreFoundation 0x2add4c6f CFReadStreamCopyProperty + 108 2 CFNetwork 0x2a898ae9 SPDYConnection :: isCellular () + 26 3 CFNetwork 0x2a898a91 SPDYConnection :: shouldIdleClose (double, double) + 58 4 CFNetwork 0x2a8a785b ___ZN24SPDYConnectionCacheEntry15shouldIdleCloseEdd_block_invoke + 32 5 CoreFoundation 0x2ad17c7d CFArrayApplyFunction + 34 6 CFNetwork 0x2a8a781f SPDYConnectionCacheEntry :: shouldIdleClose (double, double) + 136 7 CFNetwork 0x2a908fdb SPDYConnectionCache :: _ onqueue_purgeIdleConnections (bool) + 248 8 CFNetwork 0x2a86634d RunloopBlockContext :: _ invoke_block (void const *, void *) + 58 9 CoreFoundation 0x2ad17c7d CFArrayApplyFunction + 34 10 CFNetwork 0x2a866207 RunloopBlockContext :: perform () +180 11 CFNetwork 0x2a8660cd MultiplexerSource :: perform () + 214 12 CFNetwork 0x2a865f61 MultiplexerSource :: _ perform (void *) + 46 13 CoreFoundation 0x2adcc377 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 12 14 CoreFoundation 0x2adcb787 __CFRunLoopDoSources0 + 216 15 CoreFoundation 0x2adc9ded __CFRunLoopRun + 770 16 CoreFoundation 0x2ad18211 CFRunLoopRunSpecific + 474 17 CoreFoundation 0x2ad18023 CFRunLoopRunInMode + 104 18 CFNetwork 0x2a8cdb9f + [NSURLConnection (Loader) _resourceLoadLoop:] + 484 19 Foundation 0x2bb14b5b __NSThread__main__ + 1116 20 libsystem_pthread.dylib 0x38cd0e93 _pthread_body + 136 21 libsystem_pthread.dylib 0x38cd0e07 _pthread_start + 116 22 libsystem_pthread.dylib 0x38cceb90 thread_start + 6
Second appearance:
Thread 4 Crashed: 0 CoreFoundation 0x2c34d1dc CFBasicHashFindBucket + 10416 1 CoreFoundation 0x2c34a8eb CFDictionaryGetValue + 104 2 CFNetwork 0x2bea376d SocketStream :: copyProperty (void const *, __CFString const *) + 114 3 CoreFoundation 0x2c41dc6f CFReadStreamCopyProperty + 108 4 CFNetwork 0x2bee1ae9 SPDYConnection :: isCellular () + 26 5 CFNetwork 0x2bee1a91 SPDYConnection :: shouldIdleClose (double, double) + 58 6 CFNetwork 0x2bef085b ___ZN24SPDYConnectionCacheEntry15shouldIdleCloseEdd_block_invoke + 32 7 CoreFoundation 0x2c360c7d CFArrayApplyFunction + 34 8 CFNetwork 0x2bef081f SPDYConnectionCacheEntry :: shouldIdleClose (double, double) + 136 9 CFNetwork 0x2bf51fdb SPDYConnectionCache :: _ onqueue_purgeIdleConnections (bool) + 248 10 CFNetwork 0x2beaf34d RunloopBlockContext :: _ invoke_block (void const *, void *) + 58 11 CoreFoundation 0x2c360c7d CFArrayApplyFunction + 34 12 CFNetwork 0x2beaf207 RunloopBlockContext :: perform () +180 13 CFNetwork 0x2beaf0cd MultiplexerSource :: perform () + 214 14 CFNetwork 0x2beaef61 MultiplexerSource :: _ perform (void *) + 46 15 CoreFoundation 0x2c415377 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 12 16 CoreFoundation 0x2c414787 __CFRunLoopDoSources0 + 216 17 CoreFoundation 0x2c412ded __CFRunLoopRun + 770 18 CoreFoundation 0x2c361211 CFRunLoopRunSpecific + 474 19 CoreFoundation 0x2c361023 CFRunLoopRunInMode + 104 20 CFNetwork 0x2bf16b9f + [NSURLConnection (Loader) _resourceLoadLoop:] + 484 21 Foundation 0x2d15db5b __NSThread__main__ + 1116 22 libsystem_pthread.dylib 0x3a775e93 _pthread_body + 136 23 libsystem_pthread.dylib 0x3a775e07 _pthread_start + 116 24 libsystem_pthread.dylib 0x3a773b90 thread_start + 6
Looking at other streams, the first option appears when reachability changes. The second option appears when the application is running in the background and receives a background task callback.
I haven't really seen these crashes, they are from hockey crash reports.
Any ideas on how to track this?
source to share
AFURLConnectionOperation unfortunately uses synchronous requests. I have no idea why they chose to do it that way, but IMO what a bad way to do things; synchronous requests won't let you undo them, every request leaks a little RAM, no control over caching, etc.
I've seen the backtrace you posted above, as well as several hundred other crashes at random points in the network stack. The only explanation I can think of is that some part of NSURLConnection does not save its delegate in certain situations, and failures seem to be in direct proportion to the number of synchronous requests executed.
My advice is that if you absolutely need to make a synchronous request, roll your own synchronous wrapper class that uses NSURLConnection asynchronously from another thread and uses NSCondition to allow the calling thread to continue running after the connection ends.
As an example, consider the MPSynchronousURLRequest class that was implemented here:
https://github.com/dgatwood/mixpanel-iphone
It gives you a completely transparent replacement for sendSynchronousRequest that is completely under your control, so you can modify your code to guess with caching, handle errors in specific applications, etc.
source to share