用户发起的 qos.overcommit 导致 iOS 崩溃。什么可能会创建这个队列？

Question

我有一个实时应用程序的崩溃报告:

Crashed: com.apple.root.user-initiated-qos.overcommit
0  libobjc.A.dylib                0x21d486c8 objc_release + 7
1  libobjc.A.dylib                0x21d493a9 (anonymous namespace)::AutoreleasePoolPage::pop(void*) + 388
2  libdispatch.dylib              0x22110739 _dispatch_root_queue_drain + 1896
3  libdispatch.dylib              0x2210ffcd _dispatch_worker_thread3 + 96
4  libsystem_pthread.dylib        0x222c5b29 _pthread_wqthread + 1024
5  libsystem_pthread.dylib        0x222c5718 start_wqthread + 8

最有用的信息似乎是发生崩溃的队列的名称:com.apple.root.user-initiated-qos.overcommit。我已经检查了我所有的代码，我要么使用主队列，要么使用系统后台队列(即不是用户启动的 qos)，要么使用我自己创建的命名队列。

我的应用程序中确实包含其他 SDK，因此这些 SDK 很可能会将工作分派(dispatch)到此队列中。但在我假设是这种情况之前，我想知道是否存在 iOS 本身将工作分派(dispatch)到此队列的任何常见原因，这可能有助于我隔离代码库的区域以进​​行更仔细的检查。

我从研究 ( WWDC 2015 - Session 718 ) 了解到，当工作 dispatch_async 到没有特定“服务质量”设置的队列，来自主线程(用户交互 qos)。但如上所述，我不认为我在为所有队列命名时这样做。

那么有人知道 iOS 是否或何时使用 com.apple.root.user-initiated-qos.overcommit 队列吗？

Answer 1

这是系统创建的默认队列。各种 UI 组件和系统组件向该队列调度 block 。

当您在堆栈跟踪中看到 _dispatch_root_queue_drain 崩溃时，这意味着某个 block 已经在该队列上执行并且自动释放池正在被耗尽。通常崩溃是由释放已经释放的对象引起的，恰好“额外”释放最​​终归因于自动释放池，因为它最后运行。

很可能您已将某个对象移交给某处的系统框架，但它意外地过度释放。

编辑:Here are instructions使用 NSZombie 来追踪这些