大佬教程收集整理的这篇文章主要介绍了用户启动的qos.overcommit中的iOS崩溃.什么可能创建此队列？，大佬教程大佬觉得挺不错的，现在分享给大家，也给大家做个参考。
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是否或何时使用COR_807_11845@.apple.root.user-initiated-qos.overcommit队列？
当您在堆栈跟踪中看到_dispatch_root_queue_drain崩溃时,这意味着某个块已在该队列上执行,并且自动释放池正在耗尽.通常崩溃是由释放已经释放的对象引起的,它恰好发生了“额外”释放最终归因于自动释放池,因为它最后运行.
可能性是你已经将某个对象传递到某个系统框架,但它却意外地过度释放.
编辑：Here are instructions使用NSZombie跟踪这些
以上是大佬教程为你收集整理的用户启动的qos.overcommit中的iOS崩溃.什么可能创建此队列？全部内容，希望文章能够帮你解决用户启动的qos.overcommit中的iOS崩溃.什么可能创建此队列？所遇到的程序开发问题。
如果觉得大佬教程网站内容还不错，欢迎将大佬教程推荐给程序员好友。
本图文内容来源于网友网络收集整理提供，作为学习参考使用，版权属于原作者。
如您有任何意见或建议可联系处理。小编QQ：384754419，请注明来意。