iOS Absturz in Benutzer initiiert-qos.overcommit. Was könnte diese Warteschlange erstellen?

Question

Ich habe einen Crash-Bericht von einem Live-App:

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 

Die nützliche Information scheint der Name der Warteschlange zu sein, dass der Absturz auf aufgetreten: com.apple.root.user-initiated-qos.overcommit. Ich habe meinen gesamten Code überprüft und verwende entweder die Hauptwarteschlange, eine Systemhintergrundwarteschlange (d. H. Nicht vom Benutzer initiierte-qos) oder benannte Warteschlangen, die ich selbst erstellt habe.

Ich habe andere SDKs in meiner App, so dass die SDKs möglicherweise Arbeiten in diese Warteschlange schicken. Aber bevor ich davon ausgehe, habe ich mich gefragt, ob es gemeinsame Gründe dafür gibt, dass iOS selbst Arbeit in diese Warteschlange schickt, was mir helfen kann, Bereiche meiner Codebasis für eine nähere Betrachtung zu isolieren.

Ich verstehe, von der Erforschung (WWDC 2015 - Session 718), dass die user-initiated-qos Qualität der Service-Einstellung automatisch in eine Warteschlange angewendet werden kann, wenn die Arbeit dispatch_async auf eine Warteschlange, die eine bestimmte ‚Quality of Service‘ Einstellung hat, aus dem Haupt-Thread (Benutzer interaktive Qos). Aber wie oben beschrieben, glaube ich nicht, dass ich das tue, da ich alle meine Warteschlangen nenne.

Also weiß jemand, ob oder wann iOS die com.apple.root.user-initiated-qos.overcommit Warteschlange verwendet?

Answer 1

Dies ist eine Standardwarteschlange, die vom System erstellt wird. Verschiedene UI-Komponenten und Systemkomponenten senden Blöcke an diese Warteschlange.

Wenn Sie im Stack-Trace einen Absturz mit _dispatch_root_queue_drain sehen, bedeutet dies, dass bereits ein Block in dieser Warteschlange ausgeführt wurde und der Autorelease-Pool geleert wird. Normalerweise wird der Absturz verursacht, indem ein bereits veröffentlichtes Objekt freigegeben wird. Es passiert einfach, dass die "Extra" -Ausgabe dem Autorelease-Pool zugeordnet wird, weil sie zuletzt ausgeführt wird.

Die Wahrscheinlichkeit ist, dass Sie irgendwo ein Objekt an ein Systemframework übergeben haben, aber es wird versehentlich über-freigegeben.

edit: auch Here are instructions für NSZombie mit diesen