Segmentierungsfehler (Core Dumped) – wohin? Was ist es? und warum?

Wenn unter Linux ein Segmentierungsfehler auftritt, wird die Fehlermeldung Segmentation fault (core dumped) auf dem Terminal gedruckt (falls vorhanden) ) und das Programm wird beendet. Als C / C ++ – Entwickler passiert mir dies ziemlich oft, und ich ignoriere es normalerweise und gehe zu gdb, um meine vorherige Aktion neu zu erstellen und die ungültige Speicherreferenz erneut auszulösen. Stattdessen dachte ich, ich könnte vielleicht stattdessen diesen „Kern“ verwenden, da das Ausführen von gdb die ganze Zeit ziemlich mühsam ist und ich den Segmentierungsfehler nicht immer neu erstellen kann. P. >

Meine Fragen sind drei:

  • Wo wird dieser schwer fassbare „Kern“ abgeladen?
  • Was enthält er?
  • Was kann ich

Kommentare

  • Normalerweise benötigen Sie nur den Befehl gdb path-to-your-binary path-to-corefile, dann info stack gefolgt von Ctrl-d. Das einzig Besorgniserregende ist, dass Core-Dumping für Sie eine übliche Sache ist.
  • Nicht so sehr üblich , eher gelegentlich – meistens ‚ s aufgrund von Tippfehlern oder etwas, das ich geändert habe und ‚ das Ergebnis nicht verhindert hat.

Antwort

Wenn andere Leute aufräumen …

… finden Sie normalerweise nichts. Aber zum Glück hat Linux Ein Handler dafür, den Sie zur Laufzeit angeben können. In /usr/src/linux/Documentation/sysctl/kernel.txt finden Sie:

[/ proc / sys / kernel /] core_pattern wird verwendet, um einen Kern-Dumpfile-Musternamen anzugeben.

  • Wenn das erste Zeichen von Das Muster ist ein „|“. Der Kernel behandelt den Rest des Musters als einen auszuführenden Befehl. Der Core-Dump wird in die Standardeingabe dieses Programms anstatt in eine Datei geschrieben.

( danke )

A. Laut der Quelle wird dies vom Programm abrt (das Automatic Bug Reporting Tool, nicht abgebrochen) behandelt, aber unter meinem Arch Linux wird es von systemd behandelt. Möglicherweise möchten Sie Ihren eigenen Handler schreiben oder das aktuelle Verzeichnis verwenden.

Aber was ist da drin?

Nun ist das, was es enthält, systemspezifisch, aber gemäß die allwissende Enzyklopädie :

[Ein Core Dump] besteht aus dem aufgezeichneten Zustand des Arbeitsspeichers eines Computerprogramms zu einem bestimmten Zeitpunkt […]. In der Praxis werden andere Schlüsselelemente des Programmzustands normalerweise gleichzeitig ausgegeben, einschließlich der Prozessorregister, die den Programmzähler und den Stapelzeiger, Speicherverwaltungsinformationen, enthalten können. und andere Prozessor- und Betriebssystem-Flags und -Informationen.

… enthält also im Grunde alles, was gdb jemals war wollte und mehr.

Ja, aber ich möchte, dass ich glücklich bin anstatt gdb

Sie können beide glücklich sein, da gdb lädt jeden Core-Dump, solange Sie eine genaue Kopie Ihrer ausführbaren Datei haben: gdb path/to/binary my/core.dump. Sie sollten dann in der Lage sein, das Geschäft wie gewohnt fortzusetzen und sich zu ärgern, wenn Sie versuchen, Fehler zu beheben, anstatt Fehler zu reproduzieren.

Antwort

Wenn ulimit -c 0 zurückgibt, wird keine Core-Dump-Datei geschrieben.

Siehe Wo soll nach der Kerndatei gesucht werden, die durch den Absturz einer Linux-Anwendung generiert wurde?

Sie können dies auch Lösen Sie einen Core-Dump manuell mit STRG \ aus, wodurch der Prozess beendet und ein Core-Dump verursacht wird.

Antwort

Die Kerndatei heißt normalerweise core und befindet sich im aktuellen Arbeitsverzeichnis des Prozesses. Es gibt jedoch eine lange Liste von Gründen, warum eine Kerndatei nicht generiert wird, und sie befindet sich möglicherweise vollständig an einer anderen Stelle unter einem anderen Namen. Weitere Informationen finden Sie in der Manpage core.5 :

BESCHREIBUNG

Die Standardaktion bestimmter Signale besteht darin, einen Prozess zu beenden und eine Core-Dump-Datei zu erstellen. a Datenträgerdatei, die ein Image des Arbeitsspeichers des Prozesses zum Zeitpunkt der Beendigung enthält. Dieses Image kann in einem Debugger (z. B. gdb (1)) verwendet werden, um den Status des Programms zum Zeitpunkt der Beendigung zu überprüfen. Eine Liste der Signale, die dazu führen, dass ein Prozess den Kern entleert, befindet sich in Signal (7).

Es gibt verschiedene Umstände, unter denen keine Core-Dump-Datei erstellt wird:

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

Außerdem kann ein Core-Dump einen Teil des Adressraums des Prozesses ausschließen, wenn der madvise ( 2) Das MADV_DONTDUMP-Flag wurde verwendet.

Benennung von Core-Dump-Dateien

Standardmäßig eine Core-Dump-Datei heißt Core, aber die Datei / proc / sys / kernel / core_pattern (seit Linux 2.6 und 2.4.21) kann so festgelegt werden, dass eine Vorlage definiert wird, mit der Core-Dump-Dateien benannt werden. Die Vorlage kann% -Spezifizierer enthalten, die beim Erstellen einer Kerndatei durch die folgenden Werte ersetzt werden:

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

Antwort

In Ubuntu wird jeder Absturz, der passiert, in / var / crash angemeldet. Der generierte Absturzbericht kann mit einem Tool-Apport

apport-unpack /var/crash/_crash_file.crash „Pfad zum Entpacken“

entpackt werden

und dann kann der Core-Dump im entpackten Bericht mit

gdb „cat gelesen werden ExecutablePath „CoreDump

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.