När ett segmenteringsfel uppstår i Linux kommer felmeddelandet Segmentation fault (core dumped)
att skrivas ut till terminalen (om något ) och programmet avslutas. Som en C / C ++ -utvecklare händer detta mig ganska ofta, och jag ignorerar vanligtvis det och går vidare till gdb
och återskapar min tidigare åtgärd för att utlösa den ogiltiga minnesreferensen igen. Istället trodde jag att jag kanske skulle kunna använda den här ”kärnan” istället, eftersom att köra gdb
hela tiden är ganska tråkigt, och jag kan inte alltid återskapa segmenteringsfelet.
Mina frågor är tre:
- Var dumpas denna svårfångade ”kärna”?
- Vad innehåller den?
- Vad kan jag göra med det?
Kommentarer
Svar
Om andra städar …
… vanligtvis hittar du ingenting. Men lyckligtvis har Linux en hanterare för detta som du kan ange vid körning. I /usr/src/linux/Documentation/sysctl/kernel.txt hittar du:
[/ proc / sys / kernel /] core_pattern används för att ange ett kärnfilmnamn.
- Om det första tecknet i mönstret är ett ”|”, kärnan behandlar resten av mönstret som ett kommando att köra. Kärndumpen kommer att skrivas till standardinmatningen för det programmet istället för till en fil.
( tack )
A Enligt källan hanteras detta av abrt
-programmet (det är det automatiska felrapporteringsverktyget, inte avbryts), men på min Arch Linux hanteras det av systemd. Du kanske vill skriva din egen hanterare eller använda den aktuella katalogen.
Men vad finns där?
Vad det nu innehåller är systemspecifikt, men enligt den allvetande encyklopedin :
[En kärndump] består av det inspelade tillståndet i arbetsminnet i ett datorprogram vid en viss tidpunkt […] I praktiken dumpas vanligtvis andra viktiga bitar av programtillstånd samtidigt, inklusive processorregistren, som kan inkludera programräknaren och stackpekaren, minneshanteringsinformation, och andra processor- och operativsystemflaggor och information.
… så det innehåller i princip allt gdb
någonsin ville med mera.
Ja, men jag skulle vilja att jag skulle vara glad istället för gdb
Ni kan båda vara lyckliga eftersom gdb
laddar alla kärndumpar så länge du har en exakt kopia av din körbara: gdb path/to/binary my/core.dump
. Du borde kunna fortsätta arbeta som vanligt och bli irriterad genom att försöka och inte fixa buggar istället för att försöka och inte reproducera buggar.
Svar
Om ulimit -c
också returnerar 0
kommer ingen kärndumpfil att skrivas.
Se Var ska man söka efter kärnfilen som genereras av en Linux-applikations krasch?
Du kan också utlösa en core dump manuellt med CTRL – \ som avslutar processen och orsakar en core dump.
Svar
Kärnfilen kallas normalt core
och finns i processens nuvarande arbetskatalog. Det finns dock en lång lista med skäl till varför en kärnfil inte skulle genereras, och den kan placeras någon annanstans helt, under ett annat namn. Se core.5-mansidan för detaljer:
BESKRIVNING
Standardåtgärden för vissa signaler är att få en process att avslutas och producera en core dump-fil , a diskfil som innehåller en bild av processens minne vid tidpunkten för avslutningen. Denna bild kan användas i en felsökare (t.ex. gdb (1)) för att inspektera programmets tillstånd vid den tidpunkt då det avslutades. En lista över signalerna som får en process att dumpa kärnan finns i signalen (7).
…
Det finns olika omständigheter under vilka en kärndumpfil inte produceras:
* 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.
Dessutom kan en kärndump utesluta en del av adressutrymmet i processen om madvisen ( 2) MADV_DONTDUMP-flaggan användes.
Namngivning av core dump-filer
Som standard är en core dump-fil heter core, men filen / proc / sys / kernel / core_pattern (sedan Linux 2.6 och 2.4.21) kan ställas in för att definiera en mall som används för att namnge core dump-filer. Mallen kan innehålla% specificerare som ersätts av följande värden när en kärnfil skapas:
%% 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 loggas alla kraschar som händer in i / var / crash. Den genererade kraschrapporten kan packas upp med hjälp av en verktygsapport
apport-unpack /var/crash/_crash_file.crash ”sökväg för att packa upp”
och sedan kan kärndumpen i den uppackade rapporten läsas med hjälp av
gdb ”cat ExecutablePath ”CoreDump
gdb path-to-your-binary path-to-corefile
, sedaninfo stack
följt avCtrl-d
. Det enda oroande är att core-dumping är en vanlig sak för dig.