2012-03-22 7 views
5

Mam awarię w mojej aplikacji, której nie mogę debugować dla mojego życia. Po podłączeniu i debugowaniu z Xcode na urządzeniu i NSZombieEnabled nie otrzymam awarii. Kiedy odłączam i uruchamiam aplikację samodzielnie lub z kolei NSZombieEnabled, ulega ona awarii za każdym razem.Katastrofa iOS WebTryThreadLock

Oto co mam kiedy wyłączyć NSZombieEnabled: EXC_BAD_ACCESS

bool _WebTryThreadLock(bool), 0x58a260: Multiple locks on web thread not allowed! Please file a bug. Crashing now... 
1 _ZL17_WebTryThreadLockb 
2 _ZL14WebRunLoopLockP19__CFRunLoopObservermPv 
3 __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ 
4 __CFRunLoopDoObservers 
5 __CFRunLoopRun 
6 CFRunLoopRunSpecific 
7 CFRunLoopRunInMode 
8 _ZL12RunWebThreadPv 
9 _pthread_start 
10 thread_start 

Oto ślad stosu z oblotu:

0 App 0x001ff492 testflight_backtrace + 142 
1 App 0x001fffac TFSignalHandler + 212 
2 libsystem_c.dylib 0x349e9538 _sigtramp + 48 
3 JavaScriptCore 0x34b66aee WTFReportBacktrace + 146 
4 WebCore 0x33ed5676 _ZL14WebRunLoopLockP19__CFRunLoopObservermPv + 30 
5 CoreFoundation 0x33b39b4a __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 18 
6 CoreFoundation 0x33b37d86 __CFRunLoopDoObservers + 258 
7 CoreFoundation 0x33b3804e __CFRunLoopRun + 614 
8 CoreFoundation 0x33abb4dc CFRunLoopRunSpecific + 300 
9 CoreFoundation 0x33abb3a4 CFRunLoopRunInMode + 104 
10 WebCore 0x33f7712e _ZL12RunWebThreadPv + 402 
11 libsystem_c.dylib 0x349a0c1c _pthread_start + 320 
12 libsystem_c.dylib 0x349a0ad7 thread_start + 7 

ja zanim miał tę katastrofę, a mam rozwiązano, rzucając linię do mojej metody viewDoDoad na jednym ze kontrolerów widoku, w którym wystąpił błąd:

[[NSRunLoop currentRunLoop] runUntilDate: [NSDate dateWithTimeIntervalSinceNow:0.01]]; 

Ta linia nie pomaga teraz.

Proces, który powoduje awarię aplikacji jest: Present kontroler widok akcji, Odrzuć widok akcji kontrolera, Przełącznik karcie Widok na tabViewController, Naciśnij przycisk, który przedstawia widok share2 regulatorowi

nie robię dowolny przetwarzanie w tle lub zmiana dowolnego interfejsu użytkownika, awaria następuje po naciśnięciu przycisku przedstawiającego kontroler widoku share2. Ta awaria nie zdarzyła się kilka dni temu i starałem się cofnąć wszystkie moje zmiany, aby znaleźć przyczynę problemu, ale nie miałem szczęścia.

Mam również do czyszczenia Internetu dla tego błędu, i żadna z informacji znalazłem pomógł mi.

Każda rada, która wskaże mi właściwy kierunek, zostanie bardzo doceniona, dzięki!

Odpowiedz

0

Skończyło się na powtórzeniu nawigacji między 2 ekranami problemów i od tego czasu nie miałem problemu.

Moja odpowiedź: zawsze używaj nawigacji Jabłka i nie próbuj budować własnego: P

1

Śledzenie stosu nie pomaga w ogóle, pokazuje tylko, że wyjątek został ponownie zgłoszony z innego runloopa. Potrzebujesz raportu o awarii, który również pokazuje ostatni ślad śledzenia wyjątku, aby dowiedzieć się, skąd nadchodzi.

Bez tej wiedzy to raczej szalone przypuszczenie: Zakładam, że przeglądarka wciąż działa w tle, a następnie próbuje wysłać pewne dane do swojego uczestnika. Czy ustawiłeś delegata w kontrolerze widoku udziału? Czy ustawiłeś wartość zero na viewWillDisappear lub viewDidDisappear?

P.S .: Dodana linia NSRunLoop jest brzydkim hackerem, nie powinieneś tego robić, ponieważ nie naprawia niczego na serio.

P.P.S .: Istnieją inne struktury i usługi raportowania awarii oparte na PLCrashReporter, które zapewniają ostatni ślad wstecz śledzenia wyjątku i pokazują stan wszystkich wątków zamiast tylko głównego wątku.

0

Mój był spowodowany przez sam TestFlight SDK. Usunięto "start" TestFlighta i już go nie dostaję.