Post-mortem-fejlfinding med core dumps
Lær at analysere core dumps og crashrapporter for at fejlsøge problemer, der opstod tidligere, uden live-adgang.
Post-mortem-fejlfinding med core dumps er en gratis Køreklare fejl og beredskab ved hændelser-lektion på CoddyKit. Dette er lektion 2 af 4. Du kan læse alle 3 lektioner i dette læringsspor gratis i deres fulde længde — derefter låser CoddyKit PRO alle lektioner op samt praktiske øvelser med en indbygget kodeeditor og en AI-underviser døgnet rundt. Den er en del af læringsforløbet i Køreklare fejl og beredskab ved hændelser, og dine fremskridt synkroniseres på tværs af nettet og CoddyKit-appen. Køreklare fejl og beredskab ved hændelser-kurset indeholder 4 lektioner i alt.
Fejlfinding efter hændelsen
Velkommen! I denne lektion udforsker vi post-mortem-fejlfinding. Denne effektive teknik lader dig undersøge softwarefejl efter, at de er opstået, uden at du behøver genskabe problemet i drift.
Det er særligt nyttigt, når du ikke kan tilslutte en fejlfindingsklient direkte til en applikation, der går ned, især i produktionsmiljøer.
Hvad er en kernedump?
Grundlaget for post-mortem-fejlfinding er kernedumpen. Forestil dig den som et øjebliksbillede af et programs samlede hukommelsesområde og CPU-tilstand på præcis det tidspunkt, hvor programmet gik ned.
- Det er en fil, der genereres af operativsystemet.
- Den indeholder vigtige oplysninger om programmets udførelse.
- Den hjælper dig med at forstå, hvorfor et nedbrud opstod.
Hvornår opstår kernedumps?
Kernedumps genereres typisk, når et program støder på en alvorlig, uhåndteret fejl, der får det til at afslutte uventet. Almindelige scenarier omfatter:
- Segmenteringsfejl (segfaults): Adgang til ugyldig hukommelse.
- Uhåndterede undtagelser: Sprogsspecifikke fejl, som programmet ikke fanger.
- Mislykkede assertions: Når et programs interne antagelser overtrædes.
- Programnedbrud: Enhver pludselig, unormal afslutning.
Aktivering af kernedumps (Linux)
På Linux-systemer kan generering af kernedumps være deaktiveret som standard eller begrænset i størrelse. Du kan aktivere den:
- Midlertidigt: Brug
ulimit -c unlimitedi din shell-session. - For hele systemet: Rediger
/etc/sysctl.conf(f.eks.kernel.core_patternfor at angive outputsti og filnavnsformat).
Uden korrekt konfiguration gemmer systemet muligvis ikke kernedumps, når der opstår nedbrud.
Indholdet i en kernedump
En kernedump er fyldt med data til retsmedicinsk analyse. Den indeholder typisk:
- Hukommelsesafbildning: En kopi af programmets samlede virtuelle hukommelse.
- CPU-registerværdier: CPU-registernes tilstand på tidspunktet for nedbruddet.
- Stackspor: Rækkefølgen af funktionskald, der førte frem til nedbruddet.
- Procesoplysninger: Proces-id, signalet der forårsagede nedbruddet, samt den eksekverbare fils sti.
- Indlæste biblioteker: Oplysninger om delte biblioteker, der er kædet sammen med programmet.
Vigtige analyseværktøjer
For at forstå en kernedump har du brug for specialiserede værktøjer. Nogle populære værktøjer er:
- GDB (GNU Debugger): Bruges i vid udstrækning til C/C++-programmer på Linux/Unix.
- WinDbg: Microsofts effektive fejlfindingsværktøj til Windows-applikationer.
- jstack/jmap: Til Java-applikationer kan disse værktøjer udtrække tråddumps og hukommelseskort, der fungerer som en form for 'kernedump'.
- Delve: En fejlfindingsklient til Go-programmer.
Vi fokuserer på GDB som et almindeligt eksempel.
Demonstration af programnedbrud
Lad os se på et simpelt C-program, der med vilje forårsager en segmenteringsfejl. Det genererer en kernedumpfil, hvis dit system er konfigureret til det.
Prøv at kompilere og køre denne kode:
#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;
}Grundlæggende brug af GDB: Stackspor
Når programmet er gået ned og har oprettet en kernedump (f.eks. core eller core.PID), kan du indlæse den i GDB. Hvis din eksekverbare fil hedder a.out:
gdb ./a.out core
btKommandoen bt (stackspor) er vigtig. Den viser kaldestakken, der førte frem til nedbruddet, og hjælper dig med at finde den præcise funktion og det linjenummer, hvor fejlen opstod.
Inspektion af variabler med GDB
Når du har stacksporet, kan du navigere i stakrammerne (f.eks. ved hjælp af frame N, hvor N er rammenummeret). Derefter kan du inspicere variablernes værdier på det pågældende tidspunkt:
print variable_name: Viser værdien af en bestemt variabel.info locals: Viser alle lokale variabler i den aktuelle stakramme og deres værdier.
Det hjælper dig med at forstå programmets datatilstand, da det gik ned.
Quiz om kernedumps
Lad os kontrollere din forståelse af kernedumps.
Opsummering: Post-mortem-kraft
Godt arbejde! Du har lært om styrken ved post-mortem-fejlfinding ved hjælp af kernedumps.
- Kernedumps er øjebliksbilleder af hukommelsen i programmer, der er gået ned.
- De indeholder vigtige oplysninger som stackspor og variablers tilstand.
- Værktøjer som GDB hjælper med at analysere dem uden adgang til programmet i drift.
Denne teknik er uundværlig til fejlfinding af problemer, der er svære at genskabe eller kun opstår i produktion, og gør det muligt at løse problemer, selv efter at hændelsen har fundet sted.
Lær Køreklare fejl og beredskab ved hændelser med en AI-underviser — gratis
Skriv og kør rigtig kode i din browser, få øjeblikkelig hjælp fra en AI-underviser døgnet rundt, og fortsæt, hvor du slap, på web eller i appen.
- Kurser
- 12
- Lektioner
- 48
Ofte stillede spørgsmål
Er lektionen “Post-mortem-fejlfinding med core dumps” gratis?
Ja — alle 3 lektioner i læringssporet Køreklare fejl og beredskab ved hændelser, inklusive “Post-mortem-fejlfinding med core dumps”, kan læses gratis i deres fulde længde her på webstedet. Derefter låser CoddyKit PRO alle lektioner op samt interaktive øvelser med en indbygget kodeeditor og en AI-underviser døgnet rundt. Køreklare fejl og beredskab ved hændelser-kurset indeholder 4 lektioner i alt.
Hvad lærer jeg i “Post-mortem-fejlfinding med core dumps”?
Lær at analysere core dumps og crashrapporter for at fejlsøge problemer, der opstod tidligere, uden live-adgang. Du øver dig i Køreklare fejl og beredskab ved hændelser med praktisk kode, som du kører direkte i browseren, og en AI-vejleder døgnet rundt besvarer dine spørgsmål, mens du arbejder dig gennem lektionen.
Skal jeg have erfaring for at begynde på Køreklare fejl og beredskab ved hændelser?
Der kræves ingen tidligere erfaring. Køreklare fejl og beredskab ved hændelser på CoddyKit er tilrettelagt for både begyndere og øvede, så du kan starte her eller fra begyndelsen og lære i dit eget tempo. Dette er lektion 2 af 4.
Hvor lang tid tager lektionen “Post-mortem-fejlfinding med core dumps”?
De fleste CoddyKit-lektioner tager cirka 5–10 minutter. Hver lektion er kort og interaktiv, så du gør løbende fremskridt og kan fortsætte, hvor du slap – på både web og app.
Kan jeg skrive og køre kode i denne Køreklare fejl og beredskab ved hændelser-lektion?
Ja. Alle Køreklare fejl og beredskab ved hændelser-lektioner har en indbygget kodeeditor, så du kan skrive og køre rigtig kode direkte i din browser og få øjeblikkelig feedback fra AI – uden lokal opsætning.
Alle lektioner i dette kursus
- Remote debugging af live-applikationer
- Post-mortem-fejlfinding med core dumps
- Teknikker til memory- og CPU-profilering
- Distribueret tracing af latency-hotspots