用户启动的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可能会将工作分派到此队列中.但在我假设这种情况之前,我想知道是否有任何常见的原因,iOS本身会将工作分配到此队列,这可能有助于我隔离我的代码库区域以进行更仔细的检查.

我从研究(WWDC 2015 - Session 718)了解到,user-initiated-qos当工作dispatch_async进入没有特定"服务质量"设置的队列时,服务质量设置可以自动应用于队列,来自主线程(用户)互动的qos).但如上所述,我不认为我这样做,因为我列出了所有队列.

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

Answer 1

这是系统创建的默认队列。各种 UI 组件和系统组件将块分派到此队列。

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

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

编辑：以下是使用 NSZombie 追踪这些内容的说明