Håndbok for feilsøking i produksjon og hendelseshåndtering · leksjon

Feilsøking i etterkant med core-dumper

Lær å analysere core-dumper og krasjrapporter for å feilsøke problemer som oppstod tidligere, uten tilgang til systemet i sanntid

Leksjon 2 av 411 trinn

Feilsøking i etterkant med core-dumper er en gratis leksjon i Håndbok for feilsøking i produksjon og hendelseshåndtering på CoddyKit. Dette er leksjon 2 av 4. Du kan lese valgfritt 3 leksjoner fra denne læringsstien gratis i sin helhet – deretter låser CoddyKit PRO opp alle leksjoner, samt praktisk øving med en innebygd kodeeditor og en AI-veileder som er tilgjengelig døgnet rundt. Den er en del av læringsløpet i Håndbok for feilsøking i produksjon og hendelseshåndtering, og fremdriften din synkroniseres mellom nettet og CoddyKit-appen. Kurset i Håndbok for feilsøking i produksjon og hendelseshåndtering inneholder totalt 4 leksjoner.

Feilsøking i etterkant

Velkommen! I denne leksjonen skal vi utforske post-mortem-feilsøking. Med denne kraftige teknikken kan du undersøke programvarefeil etter at de har oppstått, uten å måtte gjenskape problemet mens det skjer.

Det er svært nyttig når du ikke kan koble en feilsøker direkte til en applikasjon som krasjer, særlig i produksjonsmiljøer.

Hva er en core dump?

Grunnlaget for post-mortem-feilsøking er en core dump. Tenk på den som et øyeblikksbilde av hele programmets minneområde og CPU-tilstand akkurat da det krasjet.

Det er en fil som genereres av operativsystemet.
Den inneholder viktig informasjon om programmets kjøring.
Den hjelper deg med å forstå hvorfor krasjet oppstod.

Når oppstår core dumps?

Core dumps genereres vanligvis når et program møter en alvorlig, ubehandlet feil som får det til å avsluttes uventet. Vanlige scenarioer er:

Segmentation faults (segfaults): Tilgang til ugyldig minne.
Ubehandlede unntak: Språkspesifikke feil som programmet ikke fanger opp.
Brudd på assertions: Når programmets interne antakelser brytes.
Programkrasj: Enhver plutselig og unormal avslutning.

Aktivere core dumps (Linux)

På Linux-systemer kan generering av core dumps være deaktivert som standard eller begrenset i størrelse. Du kan aktivere det slik:

Midlertidig: Bruk ulimit -c unlimited i shell-økten.
For hele systemet: Endre /etc/sysctl.conf (for eksempel kernel.core_pattern for å angi utdatabane og filnavnformat).

Uten riktig konfigurasjon kan det hende at systemet ikke lagrer core dumps når krasj oppstår.

Innholdet i en core dump

En core dump inneholder store mengder data for rettsmedisinsk analyse. Den inneholder vanligvis:

Minnespeil: En kopi av hele programmets virtuelle minne.
CPU-registerverdier: Tilstanden til CPU-registrene da krasjet oppstod.
Stack trace: Sekvensen av funksjonskall som ledet frem til krasjet.
Prosessinformasjon: Prosess-ID, signalet som forårsaket krasjet, og banen til den kjørbare filen.
Lastede biblioteker: Informasjon om delte biblioteker som er koblet til programmet.

Viktige analyseverktøy

For å forstå en core dump trenger du spesialiserte verktøy. Noen populære verktøy er:

GDB (GNU Debugger): Mye brukt for C/C++-programmer på Linux/Unix.
WinDbg: Microsofts kraftige feilsøker for Windows-applikasjoner.
jstack/jmap: For Java-applikasjoner kan disse verktøyene hente tråddumper og minnekart som fungerer som en form for «core dump».
Delve: En feilsøker for Go-programmer.

Vi fokuserer på GDB som et vanlig eksempel.

Demo: program som krasjer

La oss se på et enkelt C-program som med vilje forårsaker en segmentation fault. Dette genererer en core dump-fil hvis systemet er konfigurert for det.

Prøv å kompilere og kjøre denne koden:

#include <stdio.h>
#include <stdlib.h>

int main() {
  int *ptr = NULL; // Declare a null pointer
  printf("Attempting to dereference a null pointer...\n");
  *ptr = 10;       // This line will cause a segmentation fault
  printf("This line will not be reached.\n");
  return 0;
}

Grunnleggende GDB-bruk: backtrace

Etter at programmet krasjer og oppretter en core dump (for eksempel core eller core.PID), kan du laste den inn i GDB. Hvis den kjørbare filen heter a.out:

gdb ./a.out core
bt

Kommandoen bt (backtrace) er viktig. Den viser kallstakken som ledet frem til krasjet, slik at du kan finne den nøyaktige funksjonen og linjenummeret der feilen oppstod.

Inspisere variabler med GDB

Når du har backtrace-resultatet, kan du navigere gjennom stack-rammene (for eksempel ved å bruke frame N, der N er rammenummeret). Deretter kan du inspisere variabelverdiene på det tidspunktet:

print variable_name: Viser verdien til en bestemt variabel.
info locals: Viser alle lokale variabler i den gjeldende stack-rammen og verdiene deres.

Dette hjelper deg med å forstå tilstanden til programmets data da det krasjet.

Quiz om core dumps

La oss teste forståelsen din av core dumps.

Besvar den i den interaktive leksjonen

Oppsummering: Kraften i post-mortem-feilsøking

Godt jobbet! Du har lært om kraften i post-mortem-feilsøking ved hjelp av core dumps.

Core dumps er øyeblikksbilder av minnet til programmer som har krasjet.
De inneholder viktig informasjon, som stack traces og variabeltilstander.
Verktøy som GDB gjør det mulig å analysere dem uten tilgang til programmet mens det kjører.

Denne teknikken er uunnværlig ved feilsøking av problemer som er vanskelige å gjenskape, eller som bare oppstår i produksjon. Den gjør det mulig å løse problemer selv etter at hendelsen har funnet sted.

Gratis å komme i gang

Lær deg Håndbok for feilsøking i produksjon og hendelseshåndtering med en AI-veileder – gratis

Skriv og kjør ekte kode i nettleseren, få umiddelbar hjelp fra en AI-veileder som er tilgjengelig døgnet rundt, og fortsett der du slapp – på nettet eller i appen.

Kurs: 12
Leksjoner: 48

Start læringen gratis Se hele kurset

Ofte stilte spørsmål

Er leksjonen «Feilsøking i etterkant med core-dumper» gratis?

Ja – du kan lese valgfritt 3 av leksjonene i læringsstien Håndbok for feilsøking i produksjon og hendelseshåndtering, inkludert «Feilsøking i etterkant med core-dumper», gratis i sin helhet her på nettet. Deretter låser CoddyKit PRO opp alle leksjoner, samt interaktiv øving med en innebygd kodeeditor og en AI-veileder som er tilgjengelig døgnet rundt. Kurset i Håndbok for feilsøking i produksjon og hendelseshåndtering inneholder totalt 4 leksjoner.

Hva lærer jeg i «Feilsøking i etterkant med core-dumper»?

Lær å analysere core-dumper og krasjrapporter for å feilsøke problemer som oppstod tidligere, uten tilgang til systemet i sanntid Du øver på Håndbok for feilsøking i produksjon og hendelseshåndtering med praktisk kode som du kjører direkte i nettleseren, mens en AI-veileder som er tilgjengelig døgnet rundt, svarer på spørsmålene dine mens du jobber deg gjennom leksjonen.

Trenger jeg erfaring for å begynne med Håndbok for feilsøking i produksjon og hendelseshåndtering?

Ingen tidligere erfaring er nødvendig. Håndbok for feilsøking i produksjon og hendelseshåndtering på CoddyKit er lagt opp for både nybegynnere og viderekomne, så De kan begynne her eller helt fra start og lære i Deres eget tempo. Dette er leksjon 2 av 4.

Hvor lang tid tar leksjonen «Feilsøking i etterkant med core-dumper»?

De fleste CoddyKit-leksjoner tar omtrent 5–10 minutter. Hver leksjon er kort og interaktiv, slik at De gjør jevne fremskritt og kan fortsette akkurat der De slapp – både på nettet og i appen.

Kan jeg skrive og kjøre kode i denne Håndbok for feilsøking i produksjon og hendelseshåndtering-leksjonen?

Ja. Alle Håndbok for feilsøking i produksjon og hendelseshåndtering-leksjoner har en innebygd kodeeditor, slik at De kan skrive og kjøre ekte kode direkte i nettleseren og få umiddelbar tilbakemelding fra AI – uten lokal konfigurering.

Alle leksjonene i dette kurset

Fjernfeilsøking av aktive applikasjoner
Feilsøking i etterkant med core-dumper
Teknikker for profilering av minne og CPU
Distribuert tracing for ytelsesflaskehalser

← Tilbake til Håndbok for feilsøking i produksjon og hendelseshåndtering