Wanneer er een segmentatiefout optreedt in Linux, wordt de foutmelding Segmentation fault (core dumped) naar de terminal afgedrukt (indien aanwezig ), en het programma wordt beëindigd. Als een C / C ++ -ontwikkelaar overkomt mij dit vrij vaak, en ik negeer het meestal en ga naar gdb, waarbij ik mijn vorige actie opnieuw creëer om de ongeldige geheugenreferentie opnieuw te activeren. In plaats daarvan dacht ik dat ik in plaats daarvan misschien deze “kern” zou kunnen gebruiken, omdat het altijd vervelend is om gdb te gebruiken en ik kan de segmentatiefout niet altijd opnieuw creëren.
Mijn vragen zijn drie:
- Waar wordt deze ongrijpbare “kern” gedumpt?
- Wat staat er in?
- Wat kan ik ermee doen?
Reacties
Antwoord
Als andere mensen opruimen …
… vind je meestal niets. Maar gelukkig heeft Linux een handler hiervoor die u tijdens runtime kunt specificeren. In /usr/src/linux/Documentation/sysctl/kernel.txt vindt u:
[/ proc / sys / kernel /] core_pattern wordt gebruikt om een core dumpfile-patroonnaam te specificeren.
- Als het eerste teken van het patroon is een “|”, de kernel zal de rest van het patroon behandelen als een commando om uit te voeren. De kerndump zal naar de standaardinvoer van dat programma worden geschreven in plaats van naar een bestand.
( bedankt )
A volgens de bron wordt dit afgehandeld door het abrt programma (dat is automatische bugrapportage-tool, niet afbreken), maar op mijn Arch Linux wordt het afgehandeld door systemd. Misschien wil je je eigen handler schrijven of de huidige directory gebruiken.
Maar wat staat daar?
Wat het nu bevat is systeemspecifiek, maar volgens de alwetende encyclopedie :
[Een kerndump] bestaat uit de opgenomen toestand van het werkgeheugen van een computerprogramma op een bepaald tijdstip […]. In de praktijk worden andere belangrijke delen van de programmastatus gewoonlijk tegelijkertijd gedumpt, inclusief de processorregisters, die de programmateller en stapelaanwijzer kunnen bevatten, informatie over geheugenbeheer, en andere vlaggen en informatie over de processor en het besturingssysteem.
… dus het bevat in feite alles gdb ooit gezocht, en meer.
Ja, maar ik “zou graag willen dat ik gelukkig ben in plaats van gdb
Jullie kunnen allebei gelukkig zijn sinds gdb laadt elke kerndump zolang je een exacte kopie hebt van je uitvoerbare bestand: gdb path/to/binary my/core.dump. U zou dan gewoon door moeten kunnen gaan met uw zaken en geïrriteerd raken door te proberen en niet om bugs op te lossen in plaats van te proberen bugs te reproduceren en niet te reproduceren.
Antwoord
Als ulimit -c 0 retourneert, wordt er geen kerndumpbestand geschreven.
Zie Waar kan ik zoeken naar het kernbestand dat is gegenereerd door de crash van een Linux-applicatie?
U kunt ook activeer handmatig een core-dump met CTRL – \ die het proces afsluit en een core-dump veroorzaakt.
Answer
Het kernbestand wordt normaal gesproken core genoemd en bevindt zich in de huidige werkdirectory van het proces. Er is echter een lange lijst met redenen waarom een kernbestand niet zou worden gegenereerd, en het kan zich geheel ergens anders bevinden, onder een andere naam. Zie de core.5 man-pagina voor details:
BESCHRIJVING
De standaardactie van bepaalde signalen is ervoor te zorgen dat een proces wordt beëindigd en een kerndumpbestand , a schijfbestand met een afbeelding van het geheugen van het proces op het moment van beëindiging. Deze afbeelding kan worden gebruikt in een debugger (bijv. gdb (1)) om de status van het programma te inspecteren op het moment dat het werd beëindigd. Een lijst van de signalen die ervoor zorgen dat een proces de kern dumpt, is te vinden in signaal (7).
…
Er zijn verschillende omstandigheden waarin geen core-dumpbestand wordt geproduceerd:
* 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.Bovendien kan een core-dump een deel van de adresruimte van het proces uitsluiten als de madvise ( 2) MADV_DONTDUMP-vlag werd gebruikt.
Naamgeving van kerndumpbestanden
Standaard is een kerndumpbestand heet core, maar het bestand / proc / sys / kernel / core_pattern (sinds Linux 2.6 en 2.4.21) kan worden ingesteld om een sjabloon te definiëren die wordt gebruikt om kerndumpbestanden een naam te geven. De sjabloon kan% specificaties bevatten die worden vervangen door de volgende waarden wanneer een kernbestand wordt gemaakt:
%% 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
Answer
In Ubuntu wordt elke crash die optreedt, aangemeld bij / var / crash. Het gegenereerde crashrapport kan worden uitgepakt met behulp van een tool apport
apport-unpack /var/crash/_crash_file.crash “path to unpack”
en vervolgens kan de kerndump in het uitgepakte rapport worden gelezen met
gdb “cat ExecutablePath “CoreDump
gdb path-to-your-binary path-to-corefilenodig, vervolgensinfo stackgevolgd doorCtrl-d. Het enige verontrustende is dat core-dumping een normaal iets voor je is.