Kun Linuxissa tapahtuu segmentointivirhe, virheilmoitus Segmentation fault (core dumped)
tulostetaan päätelaitteelle (jos sellaista on) ), ja ohjelma lopetetaan. C / C ++ -sovelluksena tämä tapahtuu minulle melko usein, ja yleensä jätän sen huomiotta ja siirry kohtaan gdb
ja luodaan uudelleen edellinen toimintani virheellisen muistiviitteen käynnistämiseksi uudelleen. Ajattelin sen sijaan, että voisin ehkä käyttää tätä ”ydintä” sen sijaan, koska gdb
: n juokseminen koko ajan on melko tylsiä, enkä voi aina luoda segmentointivirhettä uudelleen.
Kysymykseni ovat kolme:
- Mihin tämä vaikeasti ymmärrettävä ”ydin” kaadetaan?
- Mitä se sisältää?
- Mitä voin tehdäänkö sitä?
Kommentit
Vastaa
Jos muut ihmiset siivoavat …
… et yleensä löydä mitään. Mutta onneksi Linux on tämän käsittelijä, jonka voit määrittää ajon aikana. Kohdasta /usr/src/linux/Documentation/sysctl/kernel.txt löydät:
[/ proc / sys / kernel /] core_patternia käytetään määrittelemään ytimen dumpfile-mallinimi.
- Jos kuvio on ”|”, ydin käsittelee loput mallista suoritettavana komennona. Ydindumppi kirjoitetaan ohjelman vakiotuloon tiedoston sijaan.
( kiitos )
A c lähteen mukaan tämän käsittelee abrt
-ohjelma (automaattinen virheraportointityökalu, ei keskeytä), mutta Arch Linux -käyttöjärjestelmässäni sitä hoitaa systemd. Haluat ehkä kirjoittaa oman käsittelijän tai käyttää nykyistä hakemistoa.
Mutta mitä siellä on?
Nyt sen sisältö on järjestelmäkohtaista, mutta kaikki tietävä tietosanakirja :
[Ydinlasku] koostuu työmuistin tallennetusta tilasta tietokoneohjelman tiettynä ajankohtana […]. Käytännössä muut keskeiset ohjelmatilan osat palataan yleensä samaan aikaan, mukaan lukien prosessorirekisterit, jotka voivat sisältää ohjelmalaskurin ja pinon osoittimen, muistinhallintatiedot, ja muut suorittimen ja käyttöjärjestelmän liput ja tiedot.
… joten se sisältää periaatteessa kaiken gdb
koskaan halusi ja enemmän.
Joo, mutta haluaisin, että olisin onnellinen gdb: n sijasta
Voit molemmat olla onnellisia, koska gdb
lataa minkä tahansa ytimen dumpin, kunhan sinulla on tarkka kopio suoritettavasta tiedostostasi: gdb path/to/binary my/core.dump
. Sitten sinun pitäisi pystyä jatkamaan liiketoimintaa tavalliseen tapaan ja ärsyttämään yrittämällä ja korjaamatta virheitä sen sijaan, että yrität ja epäonnistut virheiden toistamisessa.
Vastaa
Jos ulimit -c
palauttaa 0
, ydin dump-tiedostoa ei kirjoiteta.
Katso Mistä etsiä Linux-sovelluksen kaatumisen aiheuttamaa ydintiedostoa?
Voit myös laukaise ydinjätteen poisto manuaalisesti CTRL – \ -toiminnolla, joka sulkee prosessin ja aiheuttaa ydinjätteen.
Vastaa
Ydintiedostoa kutsutaan yleensä core
ja se sijaitsee prosessin nykyisessä työhakemistossa. Siellä on kuitenkin pitkä luettelo syistä, miksi ydintiedostoa ei luoda, ja se voi sijaita kokonaan muualla, toisella nimellä. Katso yksityiskohdat core.5 man -sivulta :
KUVAUS
Tiettyjen signaalien oletustoiminto on saada prosessi päättymään ja tuottamaan ydin dump tiedosto , a levytiedosto, joka sisältää kuvan prosessin muistista päättymisen yhteydessä. Tätä kuvaa voidaan käyttää virheenkorjauksessa (esim. gdb (1)) ohjelman tilan tarkastamiseen sen päättyessä. Luettelo signaaleista, jotka aiheuttavat prosessin ytimen kaatamisen, löytyy signaalista (7).
…
On olemassa useita olosuhteet, joissa ydindump-tiedostoa ei tuoteta:
* 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.
Lisäksi ydindumppi voi sulkea osan prosessin osoitetilasta, jos madvise ( 2) MADV_DONTDUMP-lippua käytettiin.
Ydin-dump-tiedostojen nimeäminen
Oletusarvon mukaan ydin-dump-tiedosto on nimeltä ydin, mutta / proc / sys / kernel / core_pattern-tiedosto (koska Linux 2.6 ja 2.4.21) voidaan asettaa määrittelemään malli, jota käytetään ydin dump-tiedostojen nimeämiseen. Malli voi sisältää% määrittelijöitä, jotka korvataan seuraavilla arvoilla, kun ydintiedosto luodaan:
%% 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
Vastaus
Ubuntussa kaikki tapahtuvat kaatumiset kirjataan sisään / var / crash. Luodun kaatumisraportin voi purkaa työkaluportilla
apport-unpack /var/crash/_crash_file.crash ”purkamispolku”
ja sitten pakkaamattoman raportin ydinluettelon voidaan lukea käyttämällä
gdb ”cat ExecutablePath ”CoreDump
gdb path-to-your-binary path-to-corefile
, sitteninfo stack
ja sen jälkeenCtrl-d
. Ainoa huolestuttava asia on, että ydinpolkumyynti on sinulle tavallinen asia.