skriven av Reinder de Vries den 6 augusti 2020 i apputveckling, iOS

en minut går din iOS-app bra i Xcode, och nästa har den hopplöst kraschat med ett kryptiskt sigabrt-fel. Vad händer!?

i denna handledning lär du dig:

• hur man löser” Signal SIGABRT ” – felet i Xcode
• hur man använder några av felsökningsverktygen i Xcode
• vad SIGABRT står för och vad dess orsaker är
• 3 metoder för att hitta orsaken till SIGABRT

redo? Nu går vi.

1. Vad betyder” tråd 1: Signal SIGABRT”?
2. kontrollera dina uttag
3. kontrollera Stacktrace
4. gör ett Undantagsbrytpunkt
5. Vidare läsning

Vad betyder” tråd 1: Signal SIGABRT”?

felet SIGABRT står för”signal abort”. Det är en signal som skickas av iOS-operativsystemet-till en löpande app, som omedelbart kommer att avsluta appen på grund av ett runtime-fel. Det betyder i huvudsak att din app har kraschat…

Så här ser det ut i Xcode:

i skärmdumpen ser du några saker:

• till vänster ser du en lista över trådar som sprang när appen kraschade. Du ser att tråden som orsakade kraschen är huvudtråden eller”tråd 1″.
• i redigeraren ser vi den fruktade tråden 1: signal sigabrt-felet. Den har markerat rad 12 i redigeraren, klassdefinitionen av AppDelegate.
• längst ner ser du användbar felsökningsutgång. I det här fallet får du ett stacktrace och ett kryptiskt felmeddelande om att inte vara ”key value coding-compliant.”

problemet med sigabrt-felet är att det är för generiskt. Xcode säger i princip: ”Titta, din app har kraschat, det är allt vi vet.”I de flesta fall av sigabrt-felet får du lite information om vad som orsakade felet.

innan vi fortsätter, låt oss diskutera några missuppfattningar och vanliga fallgropar av SIGABRT:

• SIGABRT-felet har vanligtvis inget att göra med AppDelegate klassdeklaration, även om den belyser den raden i Xcode. Linjen är markerad eftersom det är den första raden i din app. Slösa inte bort din tid på att titta i AppDelegate – klassen, om du inte är helt säker på att felet finns där.
• stacktrace är en lista över funktionssamtal som leder fram till att appen kraschar. Det betyder inte att kodrad som orsakade felet är någonstans i stacktrace. Det är ibland, men i andra fall leder stacktrace bara till koden som kvävde på ett värde du ställde in någon annanstans i din egen kod.
• stirra inte dig blind på ett sigabrt-fel. Det finns en rationell, logisk orsak till felet. Det är förmodligen ett fel i din egen kod, och det är inget fel med det. Appar är inte magiska, ingen är ute efter att få dig, och buggar visas aldrig ur det blå. Frustrera dig inte med tankar som ”det gick bra igår!– – det gör det alltid, och nu gör det inte!

Nu när vi har etablerat en baslinje, låt oss komma till den första orsaken till SIGABRT.

kontrollera dina uttag

en vanlig orsak till” Signal SIGABRT ” är ett stavfel eller fel i dina uttag. Här är vad som hände:

• du skapade en ny vykontroll i gränssnittsbyggare och ställde in den med några gränssnittselement som knappar och etiketter
• du kopplade dessa gränssnittselement till din kod med hjälp av utloppsegenskaper, vilket skapar en koppling mellan en egenskap hos din vykontrollant och användargränssnittet i gränssnittsbyggare
• vid ett tillfälle ändrade du namnet på den ursprungliga utloppsegenskapen och din app började krascha med ett sigabrt-fel

När du använder gränssnittsbyggare för att skapa en vykontroll, kommer din app kommer att använda xib-filen för att generera Visningskontrollens användargränssnitt när din app körs (grovt sett). Vid denna tidpunkt kommer det också att ansluta uttag från XIB till egenskaperna hos view controller-klassen.

om du har ändrat namnet på en utloppsegenskap kan din app inte hitta den längre. Och på grund av det kommer det att kasta ett undantag. Vad som orsakar sigabrt-felet hanterar inte det undantaget.

Så här ser det ut i Xcode:

se vad som händer? Egenskapen heter otherButton, men uttaget kallas fortfarande knapp. Vid ett tillfälle ändrade vi utloppet – eftersom det nya namnet är bättre – och förvirrade appen, vilket gjorde att den kraschade.

på toppen av stacktrace ser vi också en annan ledtråd:

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

vad betyder det? Appen berättar för oss vid denna tidpunkt att visningskontrollen inte är nyckelvärdeskodningskompatibel för nyckeln button. Det betyder att det inte kan hitta egenskapen button på vykontrollen. Och det är sant, för vi har bytt namn på det.

iOS använder en mekanism som kallas nyckelvärdeskodning för att inspektera egenskaperna som en vykontrollant har, så den kan använda dessa egenskaper för att referera till gränssnittselement som den har skapat baserat på XIB.

hur löser du felet vid denna tidpunkt? Du kan använda 2 tillvägagångssätt:

1. du byter namn på egenskapen tillbaka till sitt ursprungliga namn
2. du tar bort utloppsanslutningen i Interface Builder och ansluter den igen med det nya utloppsegenskapsnamnet

Låt oss gå vidare!

kontrollera Stacktrace

i många fall kommer Xcode inte att visa några användbara felmeddelanden för en sigabrt-krasch. När det händer är det användbart att känna till några felsökningskommandon, till exempel bt.

Xcode har en integrerad felsökningsmiljö som heter LLDB. Det är vad du ser längst ner i Xcode när din app körs, konsolen eller felsökningsutmatningsområdet. Du ser ofta felsökningsmeddelanden här, men visste du att du också kan använda den för att mata in kommandon?

nästa gång din app kraschar, försök skriva help I LLDB. Så här:

du ser att många av LLDB-kommandona direkt motsvarar åtgärder du kan vidta med felsökaren, till exempel att ställa in brytpunkter, gå över kodrader och inspektera runtime-värden.

ett kommando är särskilt användbart. Du kan skriva in bt för att se den aktuella samtalsstacken (även kallad” backtrace ”eller”stacktrace”). Det här är en lista över alla funktioner som körde upp till den aktuella kraschen. Detta spår innehåller vanligtvis den funktion som orsakade en bugg.

här, kolla in stacktrace av ett typiskt Index utanför intervallet fel. I skärmdumpen nedan har vi medvetet orsakat det felet genom att få index 99 från en array som bara har 4 objekt. När appen kraschar kan bt berätta vilken kodrad som orsakade felet.

kan du upptäcka följande information i stacktrace?

• den kränkande koden är på rad 21 avViewController.swift, inutiviewDidLoad() funktion
• Du kan till och med se att vi använde prenumerationen ”getter” avArray
• före kraschen en hel massa av View Controller-relaterade funktionssamtal gjordes

baserat på informationen vi fick medbt, kan vi hitta den kränkande raden i vår kod och fixa den. Xcode hjälpte oss redan i det här fallet genom att markera felet i redigeraren. I vissa scenarier har du inte sådan tur, och då kan det vara till hjälp att använda kommandot bt.

en sista sak: du kan inspektera värden vid körning med kommandot print. I ovanstående scenario skulle du skriva print names ha producerat denna utgång:

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

för att skriva ut komplexa objekt, använd po. Häftig!

gör ett Undantagsbrytpunkt

Du kan använda brytpunkter för att stoppa körningen av din kod på en viss rad. Då kan du sedan inspektera värden och gå igenom funktioner.

en undantagsbrytpunkt utlöses när ett undantag inträffar i din kod. Istället för att ange på vilken rad brytpunkten utlöses, instruerar du felsökaren att stoppa kodkörning för undantag.

Undantagsbrytpunkter är användbara för att inspektera koden när ett undantag inträffar. Du kan se vilken kodrad som kastade undantaget, och du kan inspektera värden i din kod vid den tiden. Vissa undantag orsakas av buggar eller ogiltiga tillstånd i din app, så undantagsbrytpunkter är användbara för att hitta och fixa dessa buggar.

Så här kan du ställa in en undantagsbrytpunkt:

1. gå till Brytpunktnavigatorn i Xcode, genom att använda flikarna till vänster
2. Klicka längst ner till vänster +-knappen och välj Undantagsbrytpunkt
3. lämna standardinställningarna som de är (även om de är användbara att anpassa)
4. Kör din kod

När ett undantag kastas stoppas körningen av din app. Du kan nu använda felsökaren för att inspektera värden, gå igenom koden och använda LLDB-kommandon. När det är möjligt tar Xcode dig till den kodrad som orsakade undantaget.

Tänk på att ett undantag inte nödvändigtvis kraschar din app! Så när undantagsbrytpunkten är aktiverad och ett undantag inträffar stoppas din app. Att stoppa kod med en brytpunkt är inte detsamma som en appkrasch, så låt inte det förvirra dig.

till exempel kommer en undantagsbrytpunkt att utlösas av ett otillfredsställt begränsningsundantag, men det kommer inte att krascha din app. Använd undantagsbrytpunkten för att samla in extra information för sigabrt-kraschen och inaktivera den sedan när du har löst felet (tills det behövs igen).

Vidare läsning

sigabrt-felet är ganska kryptiskt och kan vara svårt att lösa. Varför kan inte Xcode bara ge användbara felmeddelanden? Det korta svaret är att det finns så många rörliga delar i iOS-utveckling att Xcode inte alltid kan avgöra orsaken till en krasch. Xcode vet inte att du felaktigt ändrade namnet på ett uttag. Det vet bara att vid anslutning av uttaget åberopades någon kod, och det orsakade ett undantag.

det betyder att du alltid ser ett fel som ligger så nära grundorsaken som möjligt. Det bästa du kan göra är att göra massor av misstag, dekryptera massor av felmeddelanden, och lära känna dem bättre. Och vad du har lärt dig i den här handledningen är hur du hittar och löser sigabrt-felet!

vill du lära dig mer? Kolla in dessa resurser:

• Kom igång med felsökning i Xcode
• förstå felet ”okänd väljare skickad till instans” i Xcode
• förstå felet ”oväntat hittat noll medan du packar upp ett valfritt värde”
• förstå felet ”användning av olöst identifierare” i Xcode
• Off-By-One-fel i Swift-programmering
• felhantering i Swift med Do-Try-Catch