3
votes

I'm seeing two different variants of this crash deep inside CFNetwork in our VOIP application:

First occurrence:

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

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 the other threads, the first variant appears to occur when the reachability changes. The second variant appears to happen when the app is running in the background and gets a background task callback.

I haven't actually observed these crashes, they're from Hockey crash reports.

Any ideas on how to track this down?

1
Can you show any code?Claudio
I haven't been able to find which application code is relevant to it. One piece of code seemingly related is +[AFURLConnectionOperation networkRequestThreadEntryPoint:]Mike C.
same here, same crash, observing this in HockeyApp too.Bersaelor
Same issue from Fabric crash reports. Anybody found what's the problem?Aliaksandr Bialiauski

1 Answers

1
votes

AFURLConnectionOperation, unfortunately, uses synchronous requests. I have no idea why they elected to do it that way, but IMO, that's a bad way to do things; synchronous requests won't let you cancel them, every request leaks a little RAM, there's no control over caching, etc.

I've seen the backtrace you posted above, along with a few hundred other crashes at random spots throughout the networking stack. The only explanation I can come up with is that some part of NSURLConnection isn't properly retaining its delegate in certain situations, and the crashes seem to be directly proportional to the number of synchronous requests made.

My advice is that if you absolutely have to make a synchronous request, roll your own synchronous wrapper class that uses NSURLConnection asynchronously from a different thread, and uses NSCondition to allow the calling thread to continue after the connection completes.

For an example, take a look at the MPSynchronousURLRequest class that I implemented here:

https://github.com/dgatwood/mixpanel-iphone

It gives you a completely transparent replacement for sendSynchronousRequest that is fully under your control, so you can modify the code to muck with caching behavior, handle errors in app-specific ways, etc.