Wie syscall_thread_switch in iOS 8.3 debuggen?

Question

Seit ich auf iOS 8.3 umgestiegen bin, stoße ich auf diesen Fehler, bei dem der Haupt-Thread in diesem Anruf hängen bleibt. Ein paar andere Threads stecken auch in diesem Anruf fest. Es gibt keinen Code in irgendeinem Thread, der zu diesem Aufruf führt, daher bin ich ratlos, warum das passiert. Es geschieht zufällig, manchmal, wenn eine Tastenleiste Element tippen, manchmal während Charts (mit ShinobiCharts) neu zu zeichnen usw.

Hier ist der Stack-Trace von Xcode:

Wer hat eine Ahnung, wie warum das passiert und wie man es repariert? Es ist sehr ärgerlich, denn wenn ich dort feststecke, muss ich die App neu starten. Beachten Sie, dass dies bisher im Simulator geschieht. Ich bin gerade dabei, diese App zu entwickeln und die meiste Zeit im Simulator zu verbringen. Ich habe den Fehler noch nicht auf einem echten Gerät gesehen, aber ich habe die App auch nicht oft auf dem Gerät ausgeführt.

Answer 1

Klopf auf Holz, aber ich denke, ich habe es herausgefunden (zumindest in meinem Fall).

Was zur Lösung führte, war die Suche nach syscall_thread_switch, die mich hier zu dieser Antwort führte: https://stackoverflow.com/a/30333203/978509

Which, wenn man sich die Backtrace sehe ich (https://gist.github.com/Shalmezad/65ff89d20aa7e0a9d094) verbunden sind, wird jedes syscall_thread_switch von OSSpinLockLockSlow voraus, Die Antwort notiert sieht wie Livelock, aber aufgrund der niedrigen CPU-Auslastung, ist deutlicher von einem Deadlock.

Als ich meinen Code durchging, stellte ich fest, dass ich für jede Hintergrundaufgabe jedes Mal eine neue dispatch_queue_t erstellte. Ich habe seit neu, wie das funktioniert, um die gleiche Warteschlange zu verwenden, die das Problem behoben hat.

Ohne weitere Informationen von nemesis (hauptsächlich einige Codeausschnitte, die zeigen, wie er Hintergrundaufgaben aufsetzt), kann ich ihre spezifische Frage nicht beantworten, dies sollte jedoch die Leute in die richtige Richtung weisen, um das Problem zu beheben.