Question

我已经开始在生产中的一些设备上看到这次崩溃。 Fabric Crashlytics和iOS提供的信息在这种情况下非常有限，我不知道如何调试它。

崩溃中唯一常见的事情是它发生在iPhone 5S / iOS 10.2.1上，但这可能只是巧合。

值得一提的是，我正在使用Alamofire (4.3.0)，其中a similar problem应该已经修复。

崩溃日志：

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

更新

添加额外的日志记录后，我发现崩溃发生在后台应用刷新期间。根据{{3}}，“app具有最多30秒的挂钟时间来执行下载操作并调用指定的完成处理程序块”。

但是，我可以在日志中看到崩溃同时发生（同一秒 - 我在崩溃日志中看不到毫秒），因为请求被触发。换句话说，系统调用func application(_ application:, performFetchWithCompletionHandler:和崩溃之间几乎没有时间。

因此，这不应该是系统杀死应用程序在后台执行中花费太多时间的情况。

Answer 1

这与AlamoFire无关。 NSURLSession和NSURLConnection堆栈非常复杂，主要用C语言编写，基于CoreFoundation，这意味着它们也无法获得ARC的好处。有可能，这是一个微妙的多线程错误，位于堆栈深处，仅在某些情况下发生，并且可能高度依赖于时序。

在这种特殊情况下，一个对象已经被填零（可能是某处的归零弱引用）并且CF堆栈的某些部分仍在使用它，并尝试取消引用该对象以使用C级API保留它，导致NULL指针取消引用。

更具体地说，您可能会看到此次崩溃：https://github.com/PhilipsHue/PhilipsHueSDK-iOS-OSX/issues/52

至于避免它，你不太可能成功。您最好的办法是确保您的应用程序在冷启动时尽快保存状态和重新启动，以便冷启动和热启动之间的区别无关紧要。

也就是说，您可能会尝试取消所有未完成的前台连接，只要您收到通知即将进入后台，然后在discretionary设置为YES的会话中重新启动它们。 / p>

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

更新

1 个答案: