Jak debugować syscall_thread_switch w iOS 8.3?

Question

Od czasu przejścia na system iOS 8.3 napotykam ten błąd, gdy główny wątek utknie w tym wywołaniu. Kilka innych wątków również utknęło w tym wywołaniu. Nie ma żadnego kodu w żadnym wątku, który prowadzi do tego połączenia, więc jestem zaskoczony, dlaczego tak się dzieje. Zdarza się losowo, czasami, gdy dotykając element pasek przycisków, czasami podczas przerysowywania wykresów (używając ShinobiCharts) itd

Oto ślad stosu z Xcode:

Ktoś ma żadnego pojęcia, dlaczego tak się dzieje i jak to naprawić? To bardzo denerwujące, ponieważ kiedy utknę tam, muszę ponownie uruchomić aplikację. Zauważ, że tak się dzieje w symulatorze. Jestem w początkowej fazie rozwoju tej aplikacji i spędzam większość czasu w symulatorze. Nie widziałem jeszcze błędu na prawdziwym urządzeniu, ale znowu nie uruchomiłem aplikacji często na urządzeniu.

Answer 1

Pukanie w drewno, ale myślę, że to wymyśliłem (przynajmniej w moim przypadku).

Co doprowadziło do rozwiązania było poszukiwanie syscall_thread_switch, co doprowadziło mnie do tego odpowiedź tutaj: https://stackoverflow.com/a/30333203/978509

Które, jeśli spojrzeć na backtrace I połączone (https://gist.github.com/Shalmezad/65ff89d20aa7e0a9d094), każdy syscall_thread_switch poprzedzony OSSpinLockLockSlow, na które odpowiedź wskazuje, że są one podobne do Livelock, ale ze względu na niskie użycie procesora, bardziej widoczne jest zakleszczenie.

Przechodząc przez mój kod, stwierdziłem, że dla każdego zadania w tle, stworzyłem za każdym razem nowy parametr dispatch_queue_t. Odkąd zmieniłem sposób działania tej samej kolejki, która prawdopodobnie rozwiązała problem.

Bez dodatkowych informacji z nemezis (głównie z fragmentów kodu pokazujących, jak konfiguruje zadania w tle), nie mogę odpowiedzieć na ich konkretne pytanie, jednak powinno to wskazywać ludziom właściwy kierunek rozwiązania problemu.