2014-06-12 17 views
9

Aplikacja My Swift uruchomiona w symulatorze iOS jest zatrzymywana w debugerze z błędem runtime EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, sub code=0x0).Diagnozowanie EXC_BAD_INSTRUCTION w bibliotece standardowej Swift

Zgodnie z WWDC 2014 Session 409 jest to zazwyczaj spowodowane niepowodzeniem asercji.

W bieżącej wersji beta produktu Xcode 6 śledzenie stosu debuggera i powyższy błąd nie dostarcza wystarczających informacji, aby zobaczyć, jaki jest problem. Jak mogę się dowiedzieć, gdzie jest problem?

Odpowiedz

5

Wydaje się, że najczęstszym źródłem tego błędu (w momencie pisania tego tekstu: Xcode 6 beta 1) jest to, że niektóre niejawnie rozpakowany opcjonalnie nieruchomość lub zmienna jest nil.

Dla wygody większość API Objective-C jest zmostkowana do Swift z implicitly unwrapped optionals. Są one oznaczone wykrzyknikiem za deklaracji typu: AnyObject[]!

  • jeśli debugger zatrzymuje się w kodzie, sprawdź tę linię i poszukać niejawnie nieopakowanych optionals które mogą być nil tam.

  • Czasami debugger zatrzymuje się z tym błędem środowiska wykonawczego głęboko w bibliotece systemu Swift. Dzieje się tak na przykład po przejściu przez zamknięcie do metod zbierania, takich jak filter, map, reduce i in. Błąd wykonania występuje wtedy w miejscu wywołania tych funkcji bibliotecznych, ale definicja może znajdować się w różnych częściach kodu, w którym zdefiniowano funkcję/zamknięcie. Szukaj tam nieopakowanych nieopakowanych opcji, które mogą być zerowe w czasie wykonywania.

Aby ustrzec Agains te rodzaje błędów mieć świadomość, że choć Swift kompilator nie zmusi Cię do obsługi potencjał nil wartości zwracane z kakao, należy użyć optional binding, optional chaining lub optional downcasting gdzie wartość zwracana z Objective -C ziemia może być nil.

Miejmy nadzieję, że przyszłe wersje kompilatora Swift zaczną emitować bardziej przydatne komunikaty diagnostyczne i błędy dla tego typowego problemu!

+1

W wersji Beta 3 otrzymujesz komunikat konsoli dotyczący efektu "Ukryty nieopakowany opcjonalny ma wartość zerową". –

3

Znalazłem (po wielu godzinach), że ten błąd może pojawić się w niewłaściwym wierszu.

Na przykład

enter image description here

Jak widać aplikacja jest upaść, gdzie jestem sprawdzanie zera, ale potem „kontynuuje”, ponieważ poprzez wydrukowanie oświadczenia. Następnie "cofa się" i ulega awarii.

Doszedłem do wniosku, że istnieje błąd mapowania źródła w XCode (7), gdzie zmienna zerowa jest un-wrap. W tym przypadku miałem zmienną (znacznie mniej w moim kodzie), która była zerowa i nie była rozpakowywana.

Problem polega na tym, że kompilator nie oznaczał rzeczywistej zmiennej, która była zerowa, oznaczył coś zupełnie innego.

Więc jeśli natkniesz się na ten paskudny błąd, przejdź przez wszystkie możliwe zmienne, które mogą być zerowe i sprawdź je w celu rozpakowania.Prawdopodobnie rozpakujesz zero, ale nie to, co mówi kompilator.

Jak wspomniano w komentarzu, jest optymalizacja kompilatora. Oto link, aby rozwiązać ten problem (i znaleźć przyczynę trasach o katastrofie)

xcode 6.1 how to disable optimization (Swift)

+2

Z twojego opisu wynika, że ​​twoja awaria ma miejsce w zoptymalizowanej kompilacji, zgaduję? Jeśli tak, to całkiem możliwe, że kompilator dokonał zmiany kolejności kodu podczas optymalizacji, więc ... ;-) – Palimondo

+0

Tak, wyłączenie tego prowadzi do linii, która naprawdę potrzebuje środka zaradczego – Aggressor

0

miałem ten sam problem jak Palimondo. Na szczęście było to po prostu kwestią upewnienia się, że zainicjowałem przedmiot przed czasem. W moim kodzie wywołałem funkcję umieszczania obrazów w UIImageViews i przekazywania elementu z tablicy. Jeszcze nie załadowałem mojej tablicy z UIImageViews, a zatem gdy kod byłby uruchomiony, powiedziałbym, że przechodziłem w nieistniejącym elemencie tablicy. Kiedy upewniłem się załadować tablicę na początku programu, błąd zniknął.

Powiązane problemy