Når der opstår en segmenteringsfejl i Linux, vil fejlmeddelelsen Segmentation fault (core dumped) blive udskrevet til terminalen (hvis nogen ), og programmet afsluttes. Som en C / C ++ -udvikling sker dette ofte med mig, og jeg ignorerer det normalt og flytter til gdb og genskaber min tidligere handling for at udløse den ugyldige hukommelsesreference igen. I stedet troede jeg, at jeg måske kunne bruge denne “kerne” i stedet, da det hele tiden er ret kedeligt at køre gdb, og jeg kan ikke altid genskabe segmenteringsfejlen.
Mine spørgsmål er tre:
- Hvor dumpes denne undvigende “kerne”?
- Hvad indeholder den?
- Hvad kan jeg gøre med det?
Kommentarer
Svar
Hvis andre rydder op …
… finder du normalt ikke noget. Men heldigvis har Linux en handler til dette, som du kan angive ved kørsel. I /usr/src/linux/Documentation/sysctl/kernel.txt finder du:
[/ proc / sys / kernel /] core_pattern bruges til at specificere et kerne dumpfile mønsternavn.
- Hvis det første tegn i mønsteret er et “|”, kernen behandler resten af mønsteret som en kommando, der skal køres. Kernedumpen skrives til standardinput for dette program i stedet for til en fil.
( tak )
A I henhold til kilden håndteres dette af abrt -programmet (det er det automatiske fejlrapporteringsværktøj, ikke afbrydes), men på min Arch Linux håndteres det af systemd. Det kan være en god idé at skrive din egen handler eller bruge den aktuelle mappe.
Men hvad er der inde?
Hvad det indeholder er nu systemspecifikt, men ifølge den alvidende encyklopædi :
[A core dump] består af den registrerede tilstand af arbejdshukommelsen af et computerprogram på et bestemt tidspunkt […] I praksis dumpes andre nøgleelementer af programtilstand normalt på samme tid, inklusive processorregistrene, som kan omfatte programtælleren og stakmarkøren, hukommelsesstyringsinformation, og andre processor- og operativsystemflag og information.
… så det indeholder grundlæggende alt gdb nogensinde ønsket og meget mere.
Ja, men jeg vil gerne have mig til at være glad i stedet for gdb
I kan begge være lykkelige, da gdb indlæser ethvert kernedump, så længe du har en nøjagtig kopi af din eksekverbare: gdb path/to/binary my/core.dump. Du skal derefter være i stand til at fortsætte forretningen som normalt og irritere dig ved at prøve og undlade at rette fejl i stedet for at prøve og ikke reproducere fejl.
Svar
Hvis ulimit -c også returnerer 0, vil der ikke blive skrevet nogen kernedumpfil.
Se Hvor skal man søge efter kernefilen genereret af nedbruddet i en Linux-applikation?
Du kan også udløse en core dump manuelt med CTRL – \ som afslutter processen og forårsager en core dump.
Svar
Kernefilen kaldes normalt core og er placeret i den aktuelle arbejdsmappe i processen. Der er dog en lang liste over grunde til, at en kernefil ikke ville blive genereret, og den kan være placeret et helt andet sted under et andet navn. Se core.5 man-siden for detaljer:
BESKRIVELSE
Standardhandlingen for visse signaler er at få en proces til at afslutte og producere en core dump-fil , a diskfil, der indeholder et billede af processens hukommelse på tidspunktet for afslutningen. Dette billede kan bruges i en debugger (f.eks. gdb (1)) til at inspicere programmets tilstand på det tidspunkt, hvor det blev afsluttet. En liste over de signaler, der får en proces til at dumpe kerne, findes i signal (7).
…
Der er forskellige omstændigheder, hvor en kerne-dumpfil ikke produceres:
* The process does not have permission to write the core file. (By default, the core file is called core or core.pid, where pid is the ID of the process that dumped core, and is created in the current working directory. See below for details on naming.) Writing the core file will fail if the directory in which it is to be created is nonwritable, or if a file with the same name exists and is not writable or is not a regular file (e.g., it is a directory or a symbolic link). * A (writable, regular) file with the same name as would be used for the core dump already exists, but there is more than one hard link to that file. * The filesystem where the core dump file would be created is full; or has run out of inodes; or is mounted read-only; or the user has reached their quota for the filesystem. * The directory in which the core dump file is to be created does not exist. * The RLIMIT_CORE (core file size) or RLIMIT_FSIZE (file size) resource limits for the process are set to zero; see getrlimit(2) and the documentation of the shell"s ulimit command (limit in csh(1)). * The binary being executed by the process does not have read permission enabled. * The process is executing a set-user-ID (set-group-ID) program that is owned by a user (group) other than the real user (group) ID of the process, or the process is executing a program that has file capabilities (see capabilities(7)). (However, see the description of the prctl(2) PR_SET_DUMPABLE operation, and the description of the /proc/sys/fs/suid_dumpable file in proc(5).) * (Since Linux 3.7) The kernel was configured without the CONFIG_COREDUMP option.Derudover kan en kerne-dump muligvis udelukke en del af procesrummet i processen, hvis madvisen ( 2) MADV_DONTDUMP-flag blev anvendt.
Navngivning af core dump-filer
Som standard er en core dump-fil kaldes core, men filen / proc / sys / kernel / core_pattern (siden Linux 2.6 og 2.4.21) kan indstilles til at definere en skabelon, der bruges til at navngive core dump-filer. Skabelonen kan indeholde% specificatorer, der erstattes af følgende værdier, når der oprettes en kernefil:
%% a single % character %c core file size soft resource limit of crashing process (since Linux 2.6.24) %d dump mode—same as value returned by prctl(2) PR_GET_DUMPABLE (since Linux 3.7) %e executable filename (without path prefix) %E pathname of executable, with slashes ("/") replaced by exclamation marks ("!") (since Linux 3.0). %g (numeric) real GID of dumped process %h hostname (same as nodename returned by uname(2)) %i TID of thread that triggered core dump, as seen in the PID namespace in which the thread resides (since Linux 3.18) %I TID of thread that triggered core dump, as seen in the initial PID namespace (since Linux 3.18) %p PID of dumped process, as seen in the PID namespace in which the process resides %P PID of dumped process, as seen in the initial PID namespace (since Linux 3.12) %s number of signal causing dump %t time of dump, expressed as seconds since the Epoch, 1970-01-01 00:00:00 +0000 (UTC) %u (numeric) real UID of dumped process
Svar
I Ubuntu bliver ethvert nedbrud, der sker, logget ind / var / crash. Den genererede nedbrudsrapport kan pakkes ud ved hjælp af en værktøjsapport
apport-unpack /var/crash/_crash_file.crash “sti til udpakning”
og derefter kan kernedumpen i den udpakkede rapport læses ved hjælp af
gdb “cat ExecutablePath “CoreDump
gdb path-to-your-binary path-to-corefile, derefterinfo stackefterfulgt afCtrl-d. Den eneste bekymrende ting er, at kernedumping er en almindelig ting for dig.