Chyba segmentace (jádro vyhozeno) – kam? Co je to? a proč?

Pokud ostatní lidé uklidí …

… obvykle nic nenajdete. Naštěstí Linux má obslužný program, který můžete zadat za běhu. V /usr/src/linux/Documentation/sysctl/kernel.txt najdete:

[/ proc / sys / kernel /] core_pattern se používá k určení názvu vzoru dumpfile jádra.

• Pokud první znak vzor je „|“, jádro bude se zbytkem vzoru zacházet jako s příkazem, který se má spustit. Výpis jádra bude zapsán na standardní vstup daného programu místo do souboru.

( děkuji )

A podle zdroje je to řešeno programem abrt (to je automatický nástroj pro hlášení chyb, není přerušen), ale na mém Arch Linuxu je to zpracováno systemd. Možná budete chtít napsat svůj vlastní obslužný program nebo použít aktuální adresář.

Ale co tam je?

To, co obsahuje, je nyní specifické pro systém, ale podle vševědoucí encyklopedie :

[výpis jádra] se skládá ze zaznamenaného stavu pracovní paměti počítačového programu v určitou dobu […]. V praxi se obvykle vypisují současně další klíčové části stavu programu, včetně registrů procesorů, které mohou zahrnovat počítadlo programu a ukazatel zásobníku, informace o správě paměti, a další příznaky a informace procesoru a operačního systému.

… takže v podstatě obsahuje vše gdb kdykoli chtěl, a další.

Ano, ale chtěl bych, abych byl šťastný místo gdb

Oba můžete být šťastní, protože gdb načte jakýkoli výpis jádra, pokud máte přesnou kopii spustitelného souboru: gdb path/to/binary my/core.dump. Pak byste měli být schopni pokračovat v práci jako obvykle a být naštvaní tím, že se pokoušíte a nedokážete opravit chyby místo toho, abyste se pokoušeli chyby reprodukovat.

Také pokud ulimit -c vrátí 0, nebude zapsán žádný soubor s výpisem jádra.

Viz Kde hledat základní soubor generovaný selháním linuxové aplikace?

Můžete také spusťte výpis jádra ručně pomocí CTRL – \ , které ukončí proces a způsobí výpis jádra.

Základní soubor se obvykle nazývá core a nachází se v aktuálním pracovním adresáři procesu. Existuje však dlouhý seznam důvodů, proč by se jádrový soubor nevygeneroval, a může být umístěn úplně někde jinde pod jiným názvem. Podrobnosti najdete na příruční stránce core.5 :

POPIS

Výchozí akcí určitých signálů je způsobit ukončení procesu a vytvoření souboru s výpisem jádra , a soubor na disku obsahující obrázek paměti procesu v době ukončení. Tento obraz lze použít v debuggeru (např. gdb (1)) ke kontrole stavu programu v době, kdy byl ukončen. Seznam signálů, které způsobují, že proces vypustí jádro, najdete v signálu (7).

…

Existuje řada okolnosti, za kterých se soubor s výpisem stavu jádra nevytvoří:

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

Kromě toho výpis jádra může vyloučit část adresního prostoru procesu, pokud madvise ( 2) Byl použit příznak MADV_DONTDUMP.

Pojmenování souborů výpisu jádra

Ve výchozím nastavení je soubor výpisu jádra je pojmenováno jádro, ale soubor / proc / sys / kernel / core_pattern (od systému Linux 2.6 a 2.4.21) lze nastavit tak, aby definoval šablonu, která se používá k pojmenování souborů s výpisem jádra. Šablona může obsahovat% specifikátorů, které jsou při vytvoření základního souboru nahrazeny následujícími hodnotami:

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

V systému Ubuntu se přihlásí jakýkoli pád, který se stane, do / var / crash. Vygenerovanou zprávu o selhání lze rozbalit pomocí nástroje apport

apport-unpack /var/crash/_crash_file.crash „cesta k rozbalení“

a poté lze základní výpis v rozbaleném přehledu přečíst pomocí

gdb „cat ExecutablePath „CoreDump