Errore di segmentazione (core dumped) – dove? che cosè? e perché?

Se altre persone puliscono …

… di solito non trovi niente. Ma fortunatamente Linux ha un gestore per questo che puoi specificare in fase di esecuzione. In /usr/src/linux/Documentation/sysctl/kernel.txt troverai:

[/ proc / sys / kernel /] core_pattern viene utilizzato per specificare un nome di pattern del file di dump di base.

• Se il primo carattere di il pattern è un “|”, il kernel tratterà il resto del pattern come un comando da eseguire. Il core dump verrà scritto nellinput standard di quel programma invece che in un file.

( grazie )

A ccsecondo i sorgenti questo è gestito dal programma abrt (quello “s Automatic Bug Reporting Tool, non interrotto), ma sul mio Arch Linux è gestito da systemd. Potresti voler scrivere il tuo gestore o usare la directory corrente.

Ma cosa cè dentro?

Ora quello che contiene è specifico del sistema, ma secondo lenciclopedia onnisciente :

[Un core dump] è costituito dallo stato registrato della memoria di lavoro di un programma per computer in un momento specifico […]. In pratica, altre parti chiave dello stato del programma vengono solitamente scaricate contemporaneamente, inclusi i registri del processore, che possono includere il contatore del programma e il puntatore dello stack, le informazioni sulla gestione della memoria, e altri flag e informazioni sul processore e sul sistema operativo.

… quindi fondamentalmente contiene tutto gdb mai voluto, e altro ancora.

Sì, ma “vorrei che fossi felice invece di gdb

Potete essere entrambi felici poiché gdb caricherà qualsiasi core dump purché tu abbia una copia esatta del tuo eseguibile: gdb path/to/binary my/core.dump. Dovresti quindi essere in grado di continuare la tua attività come al solito ed essere infastidito dal tentativo di correggere i bug senza riuscirci invece di provare e non riuscire a riprodurli.

Inoltre, se ulimit -c restituisce 0, non verrà scritto alcun file di dump principale.

Vedi Dove cercare il file principale generato dal crash di unapplicazione Linux?

Puoi anche attiva manualmente un core dump con CTRL – \ che chiude il processo e causa un core dump.

Il file core è normalmente chiamato core e si trova nella directory di lavoro corrente del processo. Tuttavia, esiste un lungo elenco di motivi per cui un file core non verrebbe generato e potrebbe trovarsi da qualche altra parte, con un nome diverso. Vedere la pagina man core.5 per i dettagli:

DESCRIPTION

Lazione predefinita di alcuni segnali è di far terminare un processo e produrre un file core dump , a file su disco contenente unimmagine della memoria del processo al momento della conclusione. Questa immagine può essere utilizzata in un debugger (ad esempio, gdb (1)) per controllare lo stato del programma nel momento in cui è terminato. Un elenco dei segnali che provocano il dump del core di un processo può essere trovato nel segnale (7).

…

Ce ne sono vari circostanze in cui non viene prodotto un file di core dump:

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

Inoltre, un core dump può escludere parte dello spazio degli indirizzi del processo se il madvise ( 2) È stato utilizzato il flag MADV_DONTDUMP.

Denominazione di file core dump

Per impostazione predefinita, un file core dump è denominato core, ma il file / proc / sys / kernel / core_pattern (a partire da Linux 2.6 e 2.4.21) può essere impostato per definire un modello che viene utilizzato per denominare i file core dump. Il modello può contenere identificatori% che vengono sostituiti dai seguenti valori quando viene creato un file principale:

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

In Ubuntu qualsiasi crash che si verifica viene registrato in / var / crash. Il rapporto di arresto anomalo generato può essere decompresso utilizzando uno strumento apport

apport-unpack /var/crash/_crash_file.crash “path to unpack”

e quindi il core dump nel rapporto decompresso può essere letto utilizzando

gdb “cat ExecutablePath “CoreDump