Segmenteringsfeil (kjernedumpet) – til hvor? hva er det? og hvorfor?

Hvis andre rydder opp …

… finner du vanligvis ikke noe. Men heldigvis har Linux en behandler for dette som du kan spesifisere ved kjøretid. I /usr/src/linux/Documentation/sysctl/kernel.txt finner du:

[/ proc / sys / kernel /] core_pattern brukes til å spesifisere et kjernedumpfilmønsternavn.

• Hvis det første tegnet i mønsteret er et «|», kjernen vil behandle resten av mønsteret som en kommando å kjøre. Kjernedumpen blir skrevet til standardinngangen til det programmet i stedet for til en fil.

( takk )

A I følge kilden håndteres dette av abrt -programmet (det er Automatic Bug Reporting Tool, not abort), men på min Arch Linux håndteres det av systemd. Det kan være lurt å skrive din egen handler eller bruke den gjeldende katalogen.

Men hva er der?

Nå inneholder den systemspesifikk, men i henhold til alvitende leksikon :

[En kjernedump] består av den registrerte tilstanden til arbeidsminnet i et dataprogram på et bestemt tidspunkt […]. I praksis blir andre nøkkelstykker av programtilstand vanligvis dumpet samtidig, inkludert prosessorregistrene, som kan omfatte programtelleren og stabelpekeren, minnestyringsinformasjon, og andre prosessor- og operativsystemflagg og informasjon.

… så den inneholder i grunn alt gdb noensinne ønsket og mer.

Ja, men jeg vil at jeg skal være lykkelig i stedet for gdb

Du kan begge være lykkelige siden gdb vil laste en hvilken som helst kjernedump så lenge du har en eksakt kopi av den kjørbare filen: gdb path/to/binary my/core.dump. Du bør da kunne fortsette virksomheten som vanlig og irritere deg ved å prøve og unnlate å fikse feil i stedet for å prøve og ikke reprodusere feil.

Kjernefilen kalles normalt core og ligger i den nåværende arbeidskatalogen for prosessen. Det er imidlertid en lang liste med grunner til at en kjernefil ikke ville bli generert, og den kan være plassert et annet sted helt, under et annet navn. Se core.5 mansiden for detaljer:

BESKRIVELSE

Standardhandlingen for visse signaler er å få en prosess til å avsluttes og produsere en core dump-fil , a diskfil som inneholder et bilde av prosessminnet på tidspunktet for avslutningen. Dette bildet kan brukes i en feilsøkingsprogram (f.eks. gdb (1)) for å inspisere tilstanden til programmet på det tidspunktet det ble avsluttet. En liste over signalene som får en prosess til å dumpe kjernen, finnes i signalet (7).

…

Det er forskjellige omstendigheter der en kjernedumpfil ikke blir produsert:

 * 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. 

I tillegg kan en kjernedumping ekskludere en del av adresseplassen til prosessen hvis madvisen ( 2) MADV_DONTDUMP-flagget ble ansatt.

Navngivning av kjernedumpfiler

Som standard er en kjernedumpfil heter core, men filen / proc / sys / kernel / core_pattern (siden Linux 2.6 og 2.4.21) kan settes til å definere en mal som brukes til å navngi core dump-filer. Malen kan inneholde% spesifiseringer som erstattes av følgende verdier når en kjernefil opprettes:

 %% 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 

I Ubuntu blir ethvert krasj som skjer logget på / var / crash. Den genererte krasjrapporten kan pakkes ut ved hjelp av en verktøyapport

apport-unpack /var/crash/_crash_file.crash «bane for å pakke ut»

og deretter kan kjernedumpen i den utpakkede rapporten leses ved hjelp av

gdb «cat ExecutablePath «CoreDump