我有一个实时应用程序的崩溃报告:
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 队列吗？
最佳答案
这是系统创建的默认队列。各种 UI 组件和系统组件向该队列调度 block 。
当您在堆栈跟踪中看到 _dispatch_root_queue_drain 崩溃时，这意味着某个 block 已经在该队列上执行并且自动释放池正在被耗尽。通常崩溃是由释放已经释放的对象引起的，恰好“额外”释放最终归因于自动释放池，因为它最后运行。
很可能您已将某个对象移交给某处的系统框架，但它意外地过度释放。
编辑:Here are instructions使用 NSZombie 来追踪这些
关于用户发起的 qos.overcommit 导致 iOS 崩溃。什么可能会创建这个队列？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/37414918/