iOS：调试神秘的CFNetwork<redacted> 在后台获取期间在 com.apple.NSURLConnectionLoader 线程上崩溃

Question

I have started seeing this crash on a few devices in production. The info provided by Fabric Crashlytics and iOS is very limited in this case and I'm not sure how to debug it.

The only thing that's common for the crashes is it happened on iPhone 5S / iOS 10.2.1, but that might be just a coincidence.

What's worth mentioning is that I'm using Alamofire (4.3.0) where a similar problem should have been already fixed.

Crashlog:

EXC_BAD_ACCESS KERN_INVALID_ADDRESS 0x0000000000000020

Crashed: com.apple.NSURLConnectionLoader
0  libobjc.A.dylib                0x189c400a0 objc_retain + 16
1  CFNetwork                      0x18b92d1d4 <redacted> + 240
2  CFNetwork                      0x18b888e68 <redacted> + 348
3  CFNetwork                      0x18b95dc80 <redacted> + 104
4  CFNetwork                      0x18b95dc0c <redacted> + 36
5  CFNetwork                      0x18b8f32ac <redacted> + 332
6  CFNetwork                      0x18b8f3120 <redacted> + 60
7  CFNetwork                      0x18b8f30b8 <redacted> + 268
8  CFNetwork                      0x18b865040 <redacted> + 116
9  CFNetwork                      0x18b7f7290 <redacted> + 48
10 CFNetwork                      0x18b7f71c4 <redacted> + 220
11 CFNetwork                      0x18b7f5550 <redacted> + 128
12 CFNetwork                      0x18b92ca7c <redacted> + 1904
13 CFNetwork                      0x18b92c23c <redacted> + 144
14 CFNetwork                      0x18b92e18c <redacted> + 28
15 libdispatch.dylib              0x18a07a1bc _dispatch_client_callout + 16
16 libdispatch.dylib              0x18a085ab0 _dispatch_block_invoke_direct + 376
17 CFNetwork                      0x18ba2a598 <redacted> + 36
18 CoreFoundation                 0x18b0c9c18 CFArrayApplyFunction + 68
19 CFNetwork                      0x18ba2a47c <redacted> + 136
20 CFNetwork                      0x18ba2b7a4 <redacted> + 312
21 CFNetwork                      0x18ba2b510 <redacted> + 64
22 CoreFoundation                 0x18b19eb5c __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 24
23 CoreFoundation                 0x18b19e4a4 __CFRunLoopDoSources0 + 524
24 CoreFoundation                 0x18b19c0a4 __CFRunLoopRun + 804
25 CoreFoundation                 0x18b0ca2b8 CFRunLoopRunSpecific + 444
26 CFNetwork                      0x18b8cfa70 <redacted> + 336
27 Foundation                     0x18bd04e68 __NSThread__start__ + 1024
28 libsystem_pthread.dylib        0x18a285850 <redacted> + 240
29 libsystem_pthread.dylib        0x18a285760 _pthread_start + 282
30 libsystem_pthread.dylib        0x18a282d94 thread_start + 4

Update:

After adding extra logging, I have found out that the crash is happening during Background App Refresh . According to the documentation the "app has up to 30 seconds of wall-clock time to perform the download operation and call the specified completion handler block".

However, I can see in the logs that the crash occurs at the same time (the same second - I can't see the milliseconds in the crash logs) as the request is being fired. In other words, there's almost no time between the system calls func application(_ application:, performFetchWithCompletionHandler: and the crash.

Therefore, this should not be the case where the system kills the app for spending too much time in the background execution.

Answer 1

This has nothing to do with AlamoFire. The NSURLSession and NSURLConnection stack are insanely complex, and are largely written in C based on CoreFoundation, which means they also don't get the benefits of ARC. Chances are, this is a subtle multithreading bug somewhere deep in the stack that only occurs in certain circumstances, and is probably highly timing-dependent.

In this particular case, an object has gotten nilled out (probably by a zeroing weak reference somewhere) and some part of the CF stack is still using it, and tries to dereference the object to retain it using C-level APIs, resulting in a NULL pointer dereference.

More specifically, you're probably seeing this crash: https://github.com/PhilipsHue/PhilipsHueSDK-iOS-OSX/issues/52

As for avoiding it, you are unlikely to be successful. Your best bet is to make sure your app properly saves state and relaunches as quickly as possible from a cold start so that the difference between a cold start and a warm start doesn't matter.

That said, one thing you might try is canceling all outstanding foreground connections as soon as you get notified that you're going into the background, and then restarting them in a session with discretionary set to YES.