Vad händer egentligen när program kraschar?

Du klickar på spara. Ingenting händer. Sedan fryser skärmen, ett felmeddelande dyker upp och programmet är borta – tillsammans med en timmes arbete. Vi har alla varit där. Men vad händer egentligen inuti datorn under de där kaotiska sekunderna? Ett programkrasch känns som ett mysterium, något som bara sker. I verkligheten är det resultatet av en kedja av mycket konkreta händelser på mjukvarunivå. I den här artikeln reder vi ut vad som faktiskt går fel – och varför det ibland är en funktion snarare än ett fel.

När något går snett i koden

All mjukvara är i grunden en lång rad instruktioner som processorn följer i en bestämd ordning. När ett program fungerar som det ska exekveras dessa instruktioner smidigt, en efter en, utan att något oväntat inträffar. Men kod är skriven av människor, och människor gör misstag. Ibland är felet litet och programmet hanterar det utan att du ens märker det. Andra gånger är felet tillräckligt allvarligt för att hela programmet ska kollapsa.

De vanligaste orsakerna bakom en krasch

Det finns några återkommande bovar i dramat när mjukvara slutar fungera. En av de absolut vanligaste är minnesrelaterade fel. Varje program tilldelas ett visst minnesutrymme av operativsystemet, och inom det utrymmet förväntas programmet hålla sig. Om koden av misstag försöker läsa eller skriva data utanför sitt tilldelade område uppstår vad som kallas ett segmenteringsfel. Operativsystemet upptäcker intrånget och tvångsstänger programmet omedelbart, som en säkerhetsåtgärd.

En annan vanlig orsak är så kallade null-pekaredereferenser. En pekare är en variabel som pekar på en plats i minnet. Om pekaren av någon anledning inte pekar på någonting alls, alltså är null, och koden ändå försöker använda den, uppstår ett fel som de flesta programmeringsspråk inte kan återhämta sig från.

När undantag inte fångas upp

Moderna programmeringsspråk har inbyggda mekanismer för att hantera oväntade situationer, så kallade undantag eller exceptions. Tanken är att koden ska kunna ”kasta” ett undantag när något går fel, och att en annan del av koden ska ”fånga” det och hantera situationen på ett kontrollerat sätt. Problemet uppstår när ingen del av programmet är förberedd på att hantera just det felet som uppstår. Undantaget bubblar då uppåt genom hela anropsstacken utan att fångas, tills programmet till slut inte har någon mer kod att köra och kraschar.

Det kan handla om enkla saker, som att en fil som programmet försöker öppna inte finns på den förväntade platsen, eller att ett nätverksanrop returnerar ett oväntat värde. I välskriven kod är sådana scenarion förutsedda och hanterade. I sämre skriven kod är de tidsbomber som väntar på att explodera.

Buggar som lurar i det tysta

Inte alla buggar syns direkt. Vissa fel lever i koden under lång tid utan att orsaka problem, för att de kräver en mycket specifik kombination av omständigheter för att utlösas. Det kan vara en viss skärmupplösning, ett visst operativsystem, ett visst datum eller en viss sekvens av knapptryckningar. Det är därför användare ibland upplever krascher som utvecklarna aldrig lyckats reproducera i sina egna tester. Felet finns där hela tiden, men visar sig bara under rätt, eller snarare fel, förutsättningar.

Operativsystemets roll när programmet ger upp

När ett program kraschar är det sällan hela datorn som slutar fungera. Du kan fortfarande flytta muspekaren, öppna andra program och fortsätta jobba. Det är inte en tillfällighet, utan resultatet av ett noggrant genomtänkt system för hur operativsystem hanterar mjukvara som beter sig illa.

En stötdämpare mellan program och hårdvara

Operativsystemet fungerar som en strikt mellanhand mellan program och datorns hårdvara. Varje program körs i sitt eget isolerade utrymme, kallat en process. Processen har tillgång till sina egna resurser, sitt eget minne och sin egen exekveringskontext. Den kan i normalfallet inte direkt påverka andra processer eller operativsystemets kärna.

Det är just den här isoleringen som gör att ett kraschande program inte drar med sig resten av systemet i fallet. När processen dör, dör den ensam. Operativsystemet städar upp efter den, frigör det minne den använde och stänger de filer den hade öppna.

Vad som händer i de sista sekunderna

När ett program gör något det inte får, till exempel försöker komma åt minne utanför sitt tilldelade område, skickar processorns hårdvara en signal till operativsystemet. Operativsystemet tar emot signalen och skickar i sin tur en signal till den felande processen. På Unix-baserade system som Linux och macOS kallas dessa signaler för saker som SIGSEGV, för segmenteringsfel, eller SIGABRT, för när ett program avslutar sig självt på grund av ett internt fel.

Programmet kan välja att lyssna på vissa av dessa signaler och försöka hantera dem, till exempel genom att spara data och avsluta snyggt. Men ofta är situationen så allvarlig att ingen meningsfull återhämtning är möjlig. Operativsystemet skickar då en signal som inte kan ignoreras, och processen avslutas tvångsvis.

Kraschrapporter och vad de egentligen innehåller

När ett program kraschar på moderna operativsystem skapas ofta automatiskt en kraschrapport. Den här rapporten innehåller information som kan verka obegriplig för en vanlig användare men som är ovärderlig för en utvecklare:

• En stacktrace som visar exakt vilka funktioner som anropade varandra i ögonblicket för kraschen
• Innehållet i processorns register vid krashtillfället
• Information om vilket minnesutrymme programmet använde
• Vilket operativsystem och vilken version av programmet som kördes
• Eventuella felkoder och signaler som utlöste kraschen

Dessa rapporter skickas ibland automatiskt till utvecklarna, förutsatt att du godkänt det, och utgör en av de viktigaste källorna till information när buggar ska spåras och åtgärdas.

Så skyddar moderna program dig mot dataförlust

En krasch behöver inte innebära att allt arbete är förlorat. Under de senaste decennierna har mjukvaruutvecklare arbetat hårt för att bygga in skyddsmekanismer som minimerar skadan när något går fel. Resultatet är att moderna program ofta kan återhämta sig på ett sätt som verkade magiskt för bara tjugo år sedan.

Autospar och dess begränsningar

Den mest välkända skyddsmekanismen är autospar. Program som hanterar dokument, kalkylblad eller presentationer sparar med jämna mellanrum en kopia av ditt arbete, oavsett om du aktivt tryckt på spara eller inte. Den här kopian lagras ofta separat från din ordinarie fil, i en temporär plats på hårddisken.

När programmet startas om efter en krasch söker det efter den här temporära filen och erbjuder dig att återställa den. Det är ett enkelt men effektivt system som räddat oräkneliga timmar av arbete. Dess begränsning är självklar: om kraschen skedde precis efter att autosparet gjordes för tjugo minuter sedan, kan du ändå förlora de senaste tjugo minuternas arbete.

Transaktioner och atomära operationer

I mer tekniskt avancerade sammanhang, till exempel databaser och filsystem, används ett koncept kallat transaktioner. En transaktion är en grupp av operationer som antingen alla genomförs, eller inte genomförs alls. Det finns inget mellanting.

Om ett program kraschar mitt i en transaktion rullar systemet automatiskt tillbaka till det tillstånd som gällde innan transaktionen påbörjades. Det är samma princip som används i moderna journalförande filsystem, som NTFS på Windows och ext4 på Linux. De för en logg över pågående skrivoperationer, så att filsystemet kan återställas till ett konsistent tillstånd efter ett oväntat strömavbrott eller krasch.

Feltoleranta arkitekturer i vardagsprogram

Många program i dag är byggda med en arkitektur som aktivt förutsätter att delar av systemet kan misslyckas. Webbläsare är ett bra exempel. Varje flik körs i en separat process, vilket innebär att en flik som kraschar på grund av ett trasigt skript eller ett problematiskt insticksprogram inte påverkar resten av webbläsaren. Du förlorar innehållet i den ene fliken, men dina tjugo andra flikar är orörda.

Det är ett designbeslut med direkta konsekvenser för dig som användare, och ett exempel på hur medvetenheten om att program kraschar har format hur mjukvara konstrueras från grunden.