Lorsquun défaut de segmentation se produit sous Linux, le message derreur Segmentation fault (core dumped) sera imprimé sur le terminal (le cas échéant ), et le programme sera terminé. En tant que développeur C / C ++, cela marrive assez souvent, et je lignore généralement et passe à gdb, recréant mon action précédente afin de déclencher à nouveau la référence mémoire invalide. Au lieu de cela, jai pensé que je pourrais peut-être utiliser ce « noyau » à la place, car exécuter gdb tout le temps est plutôt fastidieux, et je ne peux pas toujours recréer lerreur de segmentation.
Mes questions sont au nombre de trois:
- Où ce « core » insaisissable est-il vidé?
- Que contient-il?
- Que puis-je faire avec?
Commentaires
Réponse
Si dautres personnes nettoient …
… vous ne trouvez généralement rien. Mais heureusement, Linux a un gestionnaire pour cela que vous pouvez spécifier lors de lexécution. Dans /usr/src/linux/Documentation/sysctl/kernel.txt , vous trouverez:
[/ proc / sys / kernel /] core_pattern est utilisé pour spécifier un nom de modèle de fichier de vidage principal.
- Si le premier caractère de le motif est un « | », le noyau traitera le reste du motif comme une commande à exécuter. Le vidage de mémoire sera écrit dans lentrée standard de ce programme plutôt que dans un fichier.
( merci )
A Selon la source, ceci est géré par le programme abrt (cest loutil de rapport automatique de bogue, pas dabandon), mais sur mon Arch Linux, il est géré par systemd. Vous pouvez écrire votre propre gestionnaire ou utiliser le répertoire courant.
Mais que contient-il?
Maintenant, ce quil contient est spécifique au système, mais selon lencyclopédie omnisciente :
[Un vidage de mémoire] consiste en létat enregistré de la mémoire de travail dun programme dordinateur à un moment précis. […] En pratique, dautres éléments clés de létat du programme sont généralement vidés en même temps, y compris les registres du processeur, qui peuvent inclure le compteur de programme et le pointeur de pile, les informations de gestion de la mémoire, et dautres indicateurs et informations du processeur et du système dexploitation.
… il contient donc essentiellement tout gdb voulu, et plus.
Ouais, mais je « voudrais que je sois heureux au lieu de gdb
Vous pouvez tous les deux être heureux puisque gdb chargera nimporte quel vidage de mémoire tant que vous aurez une copie exacte de votre exécutable: gdb path/to/binary my/core.dump. Vous devriez alors être en mesure de continuer comme dhabitude et être ennuyé en essayant et en échouant de corriger les bogues au lieu dessayer et de ne pas reproduire les bogues.
Réponse
De plus, si ulimit -c renvoie 0, alors aucun fichier de vidage de mémoire ne sera écrit.
Voir Où rechercher le fichier core généré par le plantage dune application Linux?
Vous pouvez également déclencher manuellement un vidage de mémoire avec CTRL – \ qui quitte le processus et provoque un vidage de mémoire.
Réponse
Le fichier principal est normalement appelé core et se trouve dans le répertoire de travail courant du processus. Cependant, il existe une longue liste de raisons pour lesquelles un fichier core ne serait pas généré, et il peut se trouver entièrement ailleurs, sous un nom différent. Consultez la page de manuel core.5 pour plus de détails:
DESCRIPTION
Laction par défaut de certains signaux est de provoquer la fin dun processus et de produire un fichier de vidage de mémoire , a fichier disque contenant une image de la mémoire du processus au moment de la fin. Cette image peut être utilisée dans un débogueur (par exemple, gdb (1)) pour inspecter l’état du programme au moment où il s’est arrêté. Une liste des signaux qui provoquent le vidage du noyau dun processus peut être trouvée dans signal (7).
…
Il existe plusieurs circonstances dans lesquelles un fichier de vidage mémoire nest pas produit:
* 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.De plus, un vidage mémoire peut exclure une partie de lespace dadressage du processus si le madvise ( 2) Lindicateur MADV_DONTDUMP a été utilisé.
Dénomination des fichiers de vidage de mémoire
Par défaut, un fichier de vidage de mémoire est nommé core, mais le fichier / proc / sys / kernel / core_pattern (depuis Linux 2.6 et 2.4.21) peut être défini pour définir un modèle utilisé pour nommer les fichiers de vidage de mémoire. Le modèle peut contenir des% spécificateurs qui sont remplacés par les valeurs suivantes lors de la création dun fichier core:
%% 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
Réponse
Dans Ubuntu, tout crash qui se produit est connecté à / var / crash. Le rapport de plantage généré peut être décompressé à laide dun outil apport
apport-unpack /var/crash/_crash_file.crash « path to unpack »
, puis le vidage de mémoire dans le rapport décompressé peut être lu en utilisant
gdb « cat ExecutablePath « CoreDump
gdb path-to-your-binary path-to-corefile, puisinfo stacksuivi deCtrl-d. La seule chose inquiétante est que le core-dumping est une chose habituelle pour vous.