Defecțiune de segmentare (nucleul aruncat) – până unde? ce este? și de ce?

Dacă alte persoane fac curățenie …

… de obicei nu găsești nimic. Dar din fericire Linux are un handler pentru acest lucru pe care îl puteți specifica în timpul rulării. În /usr/src/linux/Documentation/sysctl/kernel.txt veți găsi:

[/ proc / sys / kernel /] core_pattern este utilizat pentru a specifica un nume de tipar de fișier de tip dumpfile.

• Dacă primul caracter al modelul este un „|”, nucleul va trata restul modelului ca o comandă de executat. Memoria de bază va fi scrisă la intrarea standard a acelui program în loc de un fișier.

( mulțumesc )

A În funcție de sursă, acest lucru este gestionat de programul abrt (instrumentul automat de raportare a erorilor, nu întrerupere), dar pe Arch Linux este gestionat de systemd. Poate doriți să vă scrieți propriul handler sau să utilizați directorul curent.

Dar ce este acolo?

Acum, ceea ce conține este specific sistemului, dar conform enciclopedia atotștiutoare :

[O memorie de bază] constă în starea înregistrată a memoriei de lucru unui program de computer la un anumit moment […]. În practică, alte piese cheie ale stării programului sunt de obicei aruncate în același timp, inclusiv registrele procesorului, care pot include contorul programului și indicatorul stivei, informațiile de gestionare a memoriei, și alte steaguri și informații despre procesor și sistem de operare.

… deci conține practic tot ceea ce gdb dorit și multe altele.

Da, dar aș vrea să fiu fericit în loc de gdb

Puteți fi amândoi fericiți, deoarece gdb va încărca orice dump de bază atâta timp cât aveți o copie exactă a executabilului dvs.: gdb path/to/binary my/core.dump. Apoi, ar trebui să puteți continua activitatea ca de obicei și să vă supărați încercând și nereușind să remediați erorile în loc să încercați și să nu reușiți să reproduceți erorile. answer „>

De asemenea, dacă ulimit -c returnează 0, atunci nu va fi scris niciun fișier de dump de bază.

Consultați Unde să căutați fișierul de bază generat de blocarea unei aplicații Linux?

De asemenea, puteți declanșează manual o descărcare de bază cu CTRL – \ care părăsește procesul și provoacă o descărcare de bază.

Fișierul de bază este numit în mod normal core și se află în directorul de lucru curent al procesului. Cu toate acestea, există o listă lungă de motive pentru care un fișier de bază nu ar fi generat și poate fi localizat în altă parte în întregime, sub un nume diferit. Consultați pagina manuală core.5 pentru detalii:

DESCRIERE

Acțiunea implicită a anumitor semnale este de a determina un proces să se termine și să producă un fișier de dump de bază , a fișier de disc care conține o imagine a memoriei procesului în momentul încheierii. Această imagine poate fi utilizată într-un depanator (de exemplu, gdb (1)) pentru a inspecta starea programului la momentul la care sa încheiat. O listă a semnalelor care determină un proces să descarce nucleul poate fi găsită în semnalul (7).

…

Există diverse circumstanțe în care nu se produce un fișier de memorie de bază:

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

În plus, o memorie de bază poate exclude o parte din spațiul de adrese al procesului, dacă mesajul ( 2) S-a utilizat pavilionul MADV_DONTDUMP.

Denumirea fișierelor core dump

În mod implicit, un fișier core dump este denumit nucleu, dar fișierul / proc / sys / kernel / core_pattern (de la Linux 2.6 și 2.4.21) poate fi setat pentru a defini un șablon care este utilizat pentru denumirea fișierelor de dump de bază. Șablonul poate conține% specificatori care sunt înlocuiți cu următoarele valori atunci când este creat un fișier de bază:

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

În Ubuntu orice blocare care se întâmplă este conectată la / var / crash. Raportul de blocare generat poate fi despachetat utilizând un instrument apport

apport-unpack /var/crash/_crash_file.crash „cale spre despachetare”

și apoi aruncarea de bază din raportul despachetat poate fi citită folosind

gdb „cat ExecutablePath „CoreDump