Szegmentációs hiba (mag ki van dobva) – hova? mi az? és miért?

Ha mások takarítanak …

… általában nem talál semmit. De szerencsére a Linux ehhez egy kezelőt, amelyet futás közben megadhat. A /usr/src/linux/Documentation/sysctl/kernel.txt részben megtalálhatja:

[/ proc / sys / kernel /] core_pattern az alap dumpfile mintanév megadására szolgál.

• Ha a a minta “|”, a kernel a minta többi részét futtatandó parancsként kezeli. A magdumpot a program szabványos bemenetére írják, nem fájlba.

( köszi )

A A forrás szerint ezt a abrt program kezeli (ez az automatikus hibabejelentő eszköz, nem megszakítja), de az Arch Linux rendszeremen a systemd kezeli. Érdemes megírnia saját kezelőjét, vagy használni az aktuális könyvtárat.

De mi van ott?

Mostantól amit tartalmaz, rendszerspecifikus, de a a mindent tudó enciklopédia :

[A mag dump] a munkamemória rögzített állapotából áll egy számítógépes programnak egy adott időpontban […]. A gyakorlatban a programállapot egyéb kulcsfontosságú darabjai általában egyszerre kerülnek ki, beleértve a processzorregisztereket, amelyek tartalmazhatják a programszámlálót és a veremmutatót, a memóriakezelési információkat, és más processzor és operációs rendszer jelzők és információk.

… tehát alapvetően mindent tartalmaz gdb akart, és még sok más.

Igen, de azt szeretném, ha boldog lennék a gdb helyett

Mindketten boldogok lehetsz, mivel gdb minden magdumpot betölt, amíg rendelkezik a futtatható fájl pontos másolatával: gdb path/to/binary my/core.dump. Ezután képesnek kell lennie arra, hogy a szokásos módon folytassa az üzleti tevékenységet, és bosszankodjon azzal, hogy megpróbálja és nem tudja kijavítani a hibákat, ahelyett, hogy megpróbálná reprodukálni a hibákat.

Az alapfájlt általában core néven hívják, és a folyamat aktuális munkakönyvtárában található. Hosszú felsorolás található azonban azokról az okokról, amelyek miatt egy alapfájl nem jön létre, és előfordulhat, hogy teljesen máshol, más néven található. A részleteket lásd a core.5 man oldalon :

LEÍRÁS

Bizonyos jelek alapértelmezett művelete az, hogy egy folyamat leáll és előállít egy core dump fájlt , a lemezfájl, amely a folyamat memóriájának képét tartalmazza a felmondáskor. Ez a kép használható egy hibakeresőben (pl. gdb (1)) annak ellenőrzésére, hogy a program mikor fejeződött be. A (7) jelben megtalálható azoknak a jeleknek a listája, amelyek miatt a folyamat magot dob ki.

…

Különféle olyan körülmények, amelyekben nem készül el egy alapvető dump fájl:

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

Ezenkívül egy mag dump ki is zárhatja a folyamat címterének egy részét, ha a madvise ( 2) MADV_DONTDUMP zászlót alkalmaztunk.

Az alap dump fájlok elnevezése

Alapértelmezés szerint egy core dump fájl neve core, de a / proc / sys / kernel / core_pattern fájl (a Linux 2.6 és 2.4.21 óta) beállítható egy sablon definiálására, amelyet a core dump fájlok megnevezésére használnak. A sablon tartalmazhat% megadókat, amelyeket az alapfájl létrehozásakor a következő értékekkel helyettesítenek:

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

Az Ubuntuban minden bekövetkező összeomlást bejelentkeznek a / var / crash könyvtárba. A létrehozott összeomlási jelentés kicsomagolható egy apport eszköz használatával.

apport-unpack /var/crash/_crash_file.crash “kicsomagolási útvonal”

, majd a kicsomagolt jelentés törzslapja kiolvasható a

gdb “cat használatával ExecutablePath “CoreDump