我有一个实时应用程序的崩溃报告：
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)中了解到,当工作是dispatch_async时,用户启动的qos服务质量设置可以自动应用于队列,该队列没有特定的“服务质量”设置,来自主线程(用户互动qos).但如上所述,我不认为我这样做,因为我列出了所有队列.
那么有人知道iOS是否或何时使用com.apple.root.user-initiated-qos.overcommit队列？
解决方法
这是系统创建的默认队列.各种UI组件和系统组件将块分派给此队列.
当您在堆栈跟踪中看到_dispatch_root_queue_drain崩溃时,这意味着某个块已在该队列上执行,并且自动释放池正在耗尽.通常崩溃是由释放已经释放的对象引起的,它恰好发生了“额外”释放最终归因于自动释放池,因为它最后运行.
可能性是你已经将某个对象传递到某个系统框架,但它却意外地过度释放.
编辑：Here are instructions使用NSZombie跟踪这些
