geschreven door Reinder de Vries op 6 augustus 2020 In App Development, iOS

De ene minuut loopt uw iOS-app prima in Xcode, en de volgende is het hopeloos gecrasht met een cryptische sigabrt fout. Wat is er aan de hand!?

in deze tutorial zult u leren:

• Hoe los je de” Signal SIGABRT ” fout in Xcode
• Hoe gebruik je een aantal van de debugger tools in Xcode
• waar SIGABRT voor staat, en wat de oorzaken zijn
• 3 benaderingen om de hoofdoorzaak van SIGABRT

Ready te vinden? Laten we gaan.

1. Wat betekent “Thread 1: Signal SIGABRT”?
2. Controleer uw Outlets
3. controleer de Stacktrace
4. Maak een uitzondering breekpunt
5. verder lezen

wat betekent” Thread 1: Signal SIGABRT”?

de fout SIGABRT staat voor “signal abort”. Het is een signaal dat wordt verzonden door iOS – het besturingssysteem – naar een draaiende app, die de app onmiddellijk zal afsluiten vanwege een runtime-fout. Het betekent in wezen dat uw app is gecrasht …

Hier is hoe het eruit ziet in Xcode:

In de screenshot zie je een paar dingen:

• links zie je een lijst van threads die liepen toen de app crashte. Je ziet dat de thread die de crash veroorzaakte de hoofd thread is, of “Thread 1”.
• in de editor zien we die gevreesde Thread 1: signal SIGABRT fout. Het heeft regel 12 in de editor gemarkeerd, de klasse definitie van AppDelegate.
• onderaan ziet u nuttige debug-uitvoer. In dit geval, krijg je een stacktrace en een cryptische foutmelding over het niet “key value coding-compliant.”

het probleem met de SIGABRT-fout is dat het te generiek is. Xcode zegt eigenlijk: “kijk, je app is gecrasht, dat is alles wat we weten.”In de meeste gevallen van de SIGABRT fout, krijg je weinig informatie over wat de fout heeft veroorzaakt.

voordat we verder gaan, laten we een paar misvattingen en gemeenschappelijke valkuilen van SIGABRT bespreken:

• De SIGABRT fout heeft meestal niets te maken met de AppDelegate klasse declaratie, hoewel het die regel in Xcode benadrukt. De regel is gemarkeerd omdat het de eerste regel code van uw app. Verspil uw tijd niet door in de klasse AppDelegate te zoeken, tenzij u absoluut zeker bent dat de bug er in zit.
• de stacktrace is een lijst met functieaanroepen die ertoe leiden dat de app crasht. Dat betekent niet dat de regel code die de fout veroorzaakte ergens in de stacktrace is. Soms wel, maar in andere gevallen leidt de stacktrace alleen maar naar de code die stikte in een waarde die je elders in je eigen code hebt ingesteld.
• staar jezelf niet blind op een SIGABRT-fout. Er is een rationele, logische oorzaak voor de fout. Het is waarschijnlijk een bug in je eigen code, en daar is niets mis mee. Apps zijn geen magie, niemand is er op uit om je te krijgen, en bugs verschijnen nooit uit het niets. Frustreer jezelf niet met gedachten als “het liep prima gisteren!”- dat doet het altijd, en nu niet meer!

nu we een baseline hebben vastgesteld, gaan we naar de eerste oorzaak van SIGABRT.

Controleer uw Outlets

een veel voorkomende oorzaak van “Signal SIGABRT” is een typefout of bug in uw outlets. Dit is er gebeurd.:

• U hebt gemaakt een nieuwe view-controller in Interface Builder, en stel deze in met een paar UI-elementen zoals knoppen en labels
• U bent verbonden, deze UI-elementen om uw code in met behulp van outlet eigenschappen, die zorgt voor een verbinding tussen een eigenschap van je view-controller en de UI-element in Interface Builder
• Op een punt dat je veranderd de naam van de eerste outlet-eigendom en uw app begon te crashen met een SIGABRT fout

Als je met Interface Builder om een weergave te maken voor de verwerking, de app zal gebruik maken van de XIB-bestand te genereren dat de weergave van de controleur UI wanneer uw app draait (grofweg). Op dit punt zal het ook outlets van de XIB aan te sluiten op Eigenschappen van de view controller klasse.

als u de naam van een outlet-eigenschap hebt gewijzigd, kan uw app deze niet meer vinden. En daarom zal het een uitzondering maken. Wat de oorzaak is van de SIGABRT fout, is niet omgaan met die uitzondering.

Dit is hoe dat eruit ziet in Xcode:

zie wat er gebeurt? De eigenschap wordt otherButton genoemd, maar de outlet wordt nog steeds button genoemd. Op een gegeven moment veranderden we de outlet – omdat de nieuwe naam is beter – en verwarde de app, waardoor het crashen.

aan de bovenkant van de stacktrace zien we ook een andere aanwijzing:

Terminating app due to uncaught exception 'NSUnknownKeyException', reason: ': this class is not key value coding-compliant for the key button.

wat betekent dat? De app vertelt ons op dit punt dat de view controller is niet key value coding compliant voor de sleutel button. Dit betekent dat het de eigenschap button niet kan vinden op de weergavecontroller. En dat is waar, want we hebben het hernoemd.

iOS gebruikt een mechanisme genaamd key value coding om de eigenschappen van een weergavecontroller te inspecteren, zodat het deze eigenschappen kan gebruiken om te verwijzen naar UI-elementen die het heeft gemaakt op basis van de XIB.

Hoe los je de bug op op dit punt? U kunt 2 benaderingen gebruiken:

1. u hernoemt de eigenschap terug naar de oorspronkelijke naam
2. u verwijdert de outlet-verbinding in Interface Builder, en sluit deze opnieuw aan met de nieuwe outlet-eigenschapsnaam

laten we verder gaan!

controleer de Stacktrace

in veel gevallen zal Xcode u geen handige foutmeldingen tonen voor een sigabrt-crash. Als dat gebeurt, is het handig om een paar debug commando ‘ s te kennen, zoals bt.

Xcode heeft een geïntegreerde debugomgeving genaamd LLDB. Het is wat je ziet aan de onderkant van Xcode wanneer uw app wordt uitgevoerd, de Console of debug output gebied. Je ziet hier vaak foutopsporingsberichten, maar wist je dat je het ook kunt gebruiken om commando ‘ s in te voeren?

de volgende keer dat uw app crasht, typ dan help in LLDB. Als volgt:

u zult zien dat veel van de LLDB commando ‘ s direct overeenkomen met acties die u kunt ondernemen met de debugger, zoals het instellen van breekpunten, het over regels met code stappen en het inspecteren van runtime waarden.

Eén commando is bijzonder nuttig. U kunt bt intypen om de huidige call stack te zien (ook “backtrace” of “stacktrace”genoemd). Dit is een lijst van alle functies die tot de huidige crash liepen. Deze trace omvat meestal de functie die een bug veroorzaakt.

Hier, Bekijk de stacktrace van een typische Index buiten bereik fout. In de screenshot hieronder hebben we die fout opzettelijk veroorzaakt door index 99 op te halen uit een array die slechts 4 items bevat. Wanneer de app crasht, kan bt ons vertellen welke regel code de fout veroorzaakte.

kunt u de volgende informatie vinden in de stacktrace?

• De gewraakte code is op lijn 21 van ViewController.swift, binnen de viewDidLoad() functie
• U kunt zelfs zien dat we het subscript “getter” van Array
• Voor de crash een hele hoop view-controller-gerelateerde functie aanroepen

op Basis van de informatie die we kregen met bt, wij kunnen u de foutieve regel in onze code en bevestig deze. Xcode heeft ons in dit geval al geholpen door de fout in de editor te markeren. In sommige scenario ‘ s heb je niet zoveel geluk, en dan kan het nuttig zijn om het bt commando te gebruiken.

een laatste ding: u kunt waarden inspecteren tijdens runtime met het print Commando. In het bovenstaande scenario zou het typen van print names deze uitvoer hebben opgeleverd:

() $R0 = 4 values { = "Ford" = "Arthur" = "Zaphod" = "Trillian"}

voor het afdrukken van complexe objecten gebruikt u po. Geweldig!

Maak een uitzondering breekpunt

u kunt breekpunten gebruiken om het uitvoeren van uw code op een bepaalde regel te stoppen. Op dat punt kunt u vervolgens waarden inspecteren en functies doorlopen.

een uitzondering breekpunt wordt geactiveerd wanneer er een uitzondering optreedt in uw code. In plaats van op te geven op welke regel het breekpunt wordt geactiveerd, instrueert u de debugger om de uitvoering van code te stoppen voor uitzonderingen.

Exception breakpoints zijn nuttig voor het inspecteren van de code wanneer een uitzondering optreedt. U kunt zien welke regel code gooide de uitzondering, en u kunt inspecteren waarden in uw code op dat punt. Sommige uitzonderingen worden veroorzaakt door bugs of ongeldige toestanden van uw app, dus uitzondering breekpunten zijn handig voor het vinden en repareren van die bugs.

zo kunt u een breekpunt voor uitzonderingen instellen:

1. ga naar de Breakpoint navigator in Xcode, gebruik de tabbladen links
2. klik linksonder +-knop en kies uitzondering breekpunt
3. laat de standaardinstellingen zoals-is (hoewel ze nuttig zijn om aan te passen)
4. Voer uw code

wanneer een uitzondering wordt gegooid, stopt het uitvoeren van uw app. U kunt nu de debugger gebruiken om waarden te inspecteren, door de code te stappen en LLDB-opdrachten te gebruiken. Indien mogelijk brengt Xcode u naar de regel code die de uitzondering veroorzaakte.

Houd er rekening mee dat een uitzondering niet noodzakelijk uw app crasht! Dus, wanneer de uitzondering breekpunt is ingeschakeld, en een uitzondering optreedt, wordt uw app gestopt. Het stoppen van code met een breekpunt is niet hetzelfde als een app crash, dus laat dat je niet verwarren.

bijvoorbeeld, een uitzondering breekpunt zal worden geactiveerd door een ontevreden beperkingen uitzondering, maar dat zal niet crashen uw app. Gebruik de uitzondering breekpunt om extra informatie te verzamelen voor de sigabrt crash, en schakel het dan uit zodra je de bug hebt opgelost (totdat het weer nodig is).

verder lezen

De SIGABRT-fout is vrij cryptisch en kan moeilijk op te lossen zijn. Waarom kan Xcode niet gewoon nuttige foutmeldingen geven? Nou, dat is een goede vraag…

het korte antwoord is dat er zoveel bewegende delen in iOS ontwikkeling zijn dat Xcode niet altijd de oorzaak van een crash kan bepalen. Xcode weet niet dat u ten onrechte de naam van een outlet veranderd. Het Weet alleen dat bij het aansluiten van de stopcontact, een aantal code werd aangeroepen, en dat veroorzaakte een uitzondering.

Dit betekent dat u altijd een fout ziet die zo dicht mogelijk bij de hoofdoorzaak ligt. Het beste wat je kunt doen is veel fouten maken, decoderen veel foutmeldingen, en krijgen om ze beter te leren kennen. En wat je in deze tutorial hebt geleerd, is hoe je de SIGABRT-fout kunt vinden en oplossen!

wilt u meer weten? Bekijk deze bronnen:

• aan de slag met debuggen in Xcode
• inzicht in de “niet-herkende Selector verzonden naar instantie” fout in Xcode
• inzicht in de “onverwacht nihil gevonden tijdens het uitpakken van een optionele waarde” fout
• inzicht in de “Gebruik van Unsolved Identifier” fout in Xcode
• Off-By-One fouten in Swift-programmering
• foutafhandeling in Swift met Do-Try-Catch