jak rozwiązać błąd SIGABRT w Xcode
Written by Reinder de Vries on August 6 2020 in App Development, iOS
w jednej chwili Twoja aplikacja na iOS działa dobrze w Xcode, a w następnej beznadziejnie zawiesiła się z tajemniczy błąd SIGABRT. Co się dzieje!?
w tym tutorialu dowiesz się:
- jak rozwiązać błąd „Signal SIGABRT” w Xcode
- Jak użyć niektórych narzędzi do debugowania w Xcode
- co oznacza SIGABRT i jakie są jego przyczyny
- 3 podejścia do znalezienia głównej przyczyny SIGABRT
gotowy? Chodźmy.
- co oznacza „Wątek 1: sygnał SIGABRT”?
- Sprawdź swoje punkty sprzedaży
- Sprawdź Stacktrace
- zrób wyjątek Breakpoint
- Czytaj dalej
co oznacza „Thread 1: Signal SIGABRT”?
błąd SIGABRT oznacza „przerwanie sygnału”. Jest to sygnał wysyłany przez system operacyjny iOS do uruchomionej aplikacji, która natychmiast zamknie aplikację z powodu błędu uruchomieniowego. Zasadniczo oznacza to, że Twoja aplikacja uległa awarii …
Oto Jak to wygląda w Xcode:
na zrzucie ekranu widać kilka rzeczy:
- po lewej stronie widać listę wątków, które działały, gdy aplikacja się zawiesiła. Widzisz, że wątek, który spowodował awarię, jest głównym wątkiem lub „wątkiem 1”.
- w edytorze widzimy ten przerażający Wątek 1: signal SIGABRT error. Podświetlono linię 12 w edytorze, definicję klasy
AppDelegate
. - na dole widzisz pomocne wyjście debugowania. W takim przypadku otrzymasz ślad stosu i tajemniczy komunikat o błędzie, że nie jest „zgodny z kodowaniem wartości klucza.”
problem z błędem SIGABRT polega na tym, że jest zbyt ogólny. Xcode zasadniczo mówi: „Spójrz, Twoja aplikacja się zawiesiła, to wszystko, co wiemy.”W większości przypadków błędu SIGABRT otrzymujesz niewiele informacji o tym, co spowodowało błąd.
zanim przejdziemy dalej, omówmy kilka nieporozumień i typowych pułapek SIGABRT:
- błąd SIGABRT zwykle nie ma nic wspólnego z deklaracją klasy
AppDelegate
, mimo że podkreśla tę linię w Xcode. Linia jest podświetlona, ponieważ jest to pierwsza linia kodu Twojej aplikacji. Nie trać czasu na szukanie w klasieAppDelegate
, chyba że jesteś absolutnie pewien, że błąd tam jest. - stacktrace to lista wywołań funkcji, które prowadzą do awarii aplikacji. Nie oznacza to, że linia kodu, która spowodowała błąd, znajduje się w dowolnym miejscu stosu. Czasami tak jest, ale w innych przypadkach układ stosu prowadzi jedynie do kodu, który dławił się wartością ustawioną gdzie indziej w swoim kodzie.
- nie gap się ślepo na błąd SIGABRT. Jest racjonalna, logiczna przyczyna błędu. To pewnie błąd w Twoim kodzie i nie ma w tym nic złego. Aplikacje nie są magiczne, nikt cię nie dopadnie, a błędy nigdy nie pojawiają się znikąd. Nie frustruj się myślami typu ” wczoraj poszło dobrze!”- zawsze tak jest, a teraz nie!
teraz, gdy ustaliliśmy linię bazową, przejdźmy do pierwszej przyczyny SIGABRT.
dowiedz się, jak tworzyć aplikacje na iOS
zacznij korzystać z iOS 14 i Swift 5
Zapisz się na mój Kurs tworzenia iOS i dowiedz się, jak tworzyć świetne aplikacje na iOS 14 z Swift 5 i Xcode 12.
Sprawdź swoje punkty sprzedaży
częstą przyczyną „Signal SIGABRT” jest literówka lub błąd w punktach sprzedaży. Oto co się stało:
- utworzyłeś nowy kontroler widoku w Interface Builder i skonfigurowałeś go za pomocą kilku elementów interfejsu użytkownika, takich jak przyciski i etykiety
- połączyłeś te elementy interfejsu użytkownika z kodem za pomocą właściwości outlet, które tworzą połączenie między właściwością kontrolera widoku a elementem interfejsu użytkownika w Interface Builder
- w pewnym momencie zmieniłeś nazwę początkowej właściwości outlet i aplikacja zaczęła zawieszać się z błędem SIGABRT
podczas korzystania z narzędzia Interface Builder do tworzenia kontrolera widoku, Twoja aplikacja użyje pliku XIB do wygenerowania interfejsu użytkownika kontrolera widoku po uruchomieniu aplikacji (z grubsza mówiąc). W tym momencie podłączy również gniazda z XIB do właściwości klasy kontrolera widoku.
jeśli zmieniłeś nazwę właściwości outlet, Twoja aplikacja nie może jej już znaleźć. I z tego powodu rzuci wyjątek. Przyczyną błędu SIGABRT nie jest obsługa tego wyjątku.
oto jak to wygląda w Xcode:
widzisz co się dzieje? Właściwość nazywa się otherButton
, ale gniazdo nadal nazywa się button. W pewnym momencie zmieniliśmy outlet – ponieważ nowa nazwa jest lepsza-i myliliśmy aplikację, co spowodowało awarię.
na górze stosu zauważamy jeszcze jedną wskazówkę:
Terminating app due to uncaught exception 'NSUnknownKeyException', reason: ': this class is not key value coding-compliant for the key button.
Co to znaczy? Aplikacja informuje nas w tym momencie, że kontroler widoku nie jest zgodny z kodowaniem wartości klucza button
. Oznacza to, że nie może znaleźć właściwości button
w kontrolerze widoku. I to prawda, ponieważ zmieniliśmy nazwę.
iOS używa mechanizmu zwanego kodowaniem wartości klucza do sprawdzania właściwości kontrolera widoku, dzięki czemu może używać tych właściwości do odwoływania się do elementów interfejsu użytkownika utworzonych na podstawie XIB.
jak rozwiązać ten błąd w tym momencie? Możesz użyć 2 podejść:
- zmieniasz nazwę właściwości z powrotem na jej pierwotną nazwę
- usuwasz połączenie wylotowe w Interface Builder i łączysz je ponownie przy użyciu nowej nazwy właściwości wylotowej
przejdźmy dalej!
szybka wskazówka: tak jak zmieniony @IBOutlet
może spowodować „Wątek 1: signal SIGABRT”, więc może błędnie zmienić nazwę akcji, tzn. z @IBAction
, spowodować błąd SIGABRT.
Sprawdź Stacktrace
w wielu przypadkach Xcode nie wyświetli żadnych przydatnych komunikatów o błędach dotyczących awarii SIGABRT. Gdy tak się stanie, warto znać kilka poleceń debugowania ,takich jakbt
.
Xcode ma zintegrowane środowisko debugowania o nazwie LLDB. To jest to, co widzisz na dole Xcode, gdy aplikacja działa, obszar wyjściowy konsoli lub debugowania. Często widzisz tutaj komunikaty debugowania, ale czy wiesz, że możesz ich używać również do wprowadzania poleceń?
następnym razem, gdy Twoja aplikacja ulegnie awarii, spróbuj wpisać help
w LLDB. W ten sposób:
zobaczysz, że wiele poleceń LLDB bezpośrednio odpowiada czynnościom, które możesz wykonać za pomocą debugera, takim jak ustawianie punktów przerwania, przekraczanie linii kodu i sprawdzanie wartości uruchomieniowych.
jedna komenda jest szczególnie przydatna. Możesz wpisać bt
, aby zobaczyć bieżący stos wywołań (zwany także” backtrace „lub”stacktrace”). Jest to lista wszystkich funkcji, które działały do bieżącego awarii. Ten ślad zazwyczaj zawiera funkcję, która spowodowała błąd.
tutaj sprawdź stacktrace typowego błędu poza zakresem indeksu. Na poniższym zrzucie ekranu celowo spowodowaliśmy ten błąd, pobierając index 99
z tablicy, która ma tylko pozycje 4. Gdy aplikacja ulegnie awarii, bt
może nam powiedzieć, która linia kodu spowodowała błąd.
Czy możesz zauważyć następujące informacje w stosie?
- kod błędu znajduje się w linii 21
ViewController.swift
, wewnątrzviewDidLoad()
funkcja - możesz nawet zobaczyć, że użyliśmy kodu „getter” z
Array
- przed awarią całą kilka wywołań funkcji związanych z kontrolerem widoku zostało wykonanych
na podstawie informacji, które otrzymaliśmy za pomocą bt
, możemy znaleźć błędną linię w naszym kodzie i ją naprawić. Xcode już pomógł nam w tym przypadku, podkreślając błąd w edytorze. W niektórych sytuacjach nie będziesz miał takiego szczęścia, a wtedy pomocne może być użycie polecenia bt
.
jeszcze jedno: możesz sprawdzać wartości w czasie wykonywania poleceniemprint
. W powyższym scenariuszu wpisanie print names
spowodowałoby takie wyjście:
() $R0 = 4 values { = "Ford" = "Arthur" = "Zaphod" = "Trillian"}
do drukowania złożonych obiektów użyj po
. Super!
należy pamiętać, że układ stosu działa na zewnątrz-w. Dolna część śledzenia stosu pokazuje wywołania funkcji najwyższego poziomu, a im wyżej znajduje się stos, tym głębsze są wywołania. Ostatnie, najnowsze, najgłębsze wywołanie znajduje się na górze stosu.
zrób wyjątek punkt przerwania
możesz użyć punktów przerwania, aby zatrzymać wykonywanie kodu w określonej linii. W tym momencie możesz sprawdzić wartości i przejść przez funkcje.
punkt przerwania wyjątku jest wyzwalany za każdym razem, gdy wystąpi wyjątek w kodzie. Zamiast określać, w której Linii Zostanie uruchomiony punkt przerwania, poinstruujesz debugera, aby wstrzymał wykonywanie kodu w przypadku WYJĄTKÓW.
punkty przerwania WYJĄTKÓW są przydatne do sprawdzania kodu, gdy wystąpi wyjątek. Możesz zobaczyć, która linia kodu wyrzuciła wyjątek i możesz sprawdzić wartości w kodzie w tym punkcie. Niektóre wyjątki są spowodowane błędami lub nieprawidłowymi Stanami aplikacji, więc punkty przerwania WYJĄTKÓW są przydatne do znajdowania i naprawiania tych błędów.
oto jak można ustawić punkt przerwania wyjątku:
- przejdź do nawigatora punktu przerwania w Xcode, korzystając z kart po lewej stronie
- kliknij na lewym dolnym rogu
+
-przycisk i wybierz wyjątek punkt przerwania - pozostaw domyślne ustawienia tak, jak są (chociaż są pomocne w dostosowaniu)
- Uruchom swój kod
gdy zostanie zgłoszony wyjątek, wykonywanie aplikacji zatrzymuje się. Możesz teraz używać debuggera do sprawdzania wartości, przechodzenia przez kod i używania poleceń LLDB. Jeśli to możliwe, Xcode przeniesie Cię do wiersza kodu, który spowodował wyjątek.
pamiętaj, że wyjątek niekoniecznie zawiesza Twoją aplikację! Tak więc za każdym razem, gdy włączony jest punkt przerwania wyjątku i wystąpi wyjątek, aplikacja jest zatrzymywana. Zatrzymanie kodu z punktem przerwania nie jest tym samym, co awaria aplikacji, więc nie pozwól, aby cię to zmyliło.
na przykład punkt przerwania wyjątku zostanie wywołany przez niezaspokojony wyjątek ograniczeń, ale nie spowoduje to awarii aplikacji. Użyj punktu przerwania wyjątku, aby zebrać dodatkowe informacje dotyczące awarii SIGABRT, a następnie wyłącz go po rozwiązaniu błędu (dopóki nie będzie on ponownie potrzebny).
dowiedz się, jak tworzyć aplikacje na iOS
zacznij korzystać z iOS 14 i Swift 5
Zapisz się na mój Kurs tworzenia iOS i dowiedz się, jak tworzyć świetne aplikacje na iOS 14 z Swift 5 i Xcode 12.
Czytaj dalej
błąd SIGABRT jest dość tajemniczy i może okazać się trudny do rozwiązania. Dlaczego Xcode nie może po prostu dać pomocnych komunikatów o błędach? Cóż, to dobre pytanie …
krótka odpowiedź jest taka, że w rozwoju iOS jest tak wiele ruchomych części, że Xcode nie zawsze może określić przyczynę awarii. Xcode nie wie, że błędnie zmieniłeś nazwę punktu sprzedaży. Wie tylko, że przy podłączaniu gniazdka został wywołany jakiś kod, co spowodowało wyjątek.
oznacza to, że zawsze zobaczysz błąd, który jest jak najbardziej zbliżony do głównej przyczyny. Najlepsze, co możesz zrobić, to popełnić wiele błędów, odszyfrować wiele komunikatów o błędach i lepiej je poznać. W tym samouczku nauczyłeś się, jak znaleźć i rozwiązać błąd SIGABRT!
chcesz dowiedzieć się więcej? Zapoznaj się z tymi Zasobami:
- zacznij od debugowania w Xcode
- zrozumienie błędu „nierozpoznanego selektora wysłanego do instancji” w Xcode
- zrozumienie błędu „nieoczekiwanie znaleziono zero podczas rozpakowywania wartości opcjonalnej”
- zrozumienie błędu „użycie nierozwiązanego identyfikatora” w Xcode
- błędy Off-by-One w programowaniu Swift
- Obsługa błędów w Swift Z Do-Try-Catch