Le noyau est vidé, mais le fichier principal ne se trouve pas dans le répertoire actuel?
Lors de l'exécution d'un programme C, il est indiqué "(core dumped)" mais je ne vois aucun fichier dans le chemin actuel.
J'ai défini et vérifié la ulimit:
ulimit -c unlimited
ulimit -a
J'ai également essayé de trouver un fichier nommé "core", mais je n'ai pas récupéré le fichier core vidé.
Toute aide, où est mon fichier de base?
Lire / usr/src/linux/Documentation/sysctl/kernel.txt .
[/ proc/sys/kernel /] core_pattern est utilisé pour spécifier un nom de modèle de fichier de dump principal.
- Si le premier caractère du modèle est un '|', le noyau considérera le reste du modèle comme une commande à exécuter. Le vidage principal sera écrit sur l'entrée standard de ce programme plutôt que sur un fichier.
Au lieu d'écrire le core dump sur le disque, votre système est configuré pour l'envoyer au programme abrt. Outil de rapport de bogue automatisé n'est peut-être pas aussi documenté que devrait être ...
Dans tous les cas, la réponse rapide est que vous devriez pouvoir trouver votre fichier de base dans /var/cache/abrt, où abrt le stocke après avoir été appelé. De même, d'autres systèmes utilisant Apport peuvent échapper des cœurs dans /var/crash, etc.
Sur Ubuntu récent (12.04 dans mon cas), il est possible d’imprimer "Défaut de segmentation (core dumped)", mais aucun fichier central ne devrait être généré (on pourrait s’attendre à ce qu’il en soit un (par exemple pour un programme compilé localement).
Cela peut arriver si vous avez une taille de fichier noyau ulimit de 0 (vous n'avez pas encore fait ulimit -c unlimited) - il s'agit de la valeur par défaut sous Ubuntu. Normalement, cela supprimerait le "(core dumped)", ce qui vous expliquerait votre erreur, mais sous Ubuntu, les corefiles sont redirigés vers Apport (système de compte rendu de crash d'Ubuntu) via /proc/sys/kernel/core_pattern, et cela semble pour provoquer le message trompeur.
Si Apport découvre que le programme en question n’est pas un programme pour lequel il doit signaler un blocage (ce qui se produit dans /var/log/apport.log), il revient à la simulation du comportement par défaut du noyau consistant à placer un fichier core dans le fichier cwd (this est fait dans le script /usr/share/apport/apport). Cela implique de respecter ulimit, auquel cas il ne fait rien. Mais (je suppose) en ce qui concerne le noyau, un corefile a été généré (et canalisé pour le répartir), d’où le message "Défaillance de la segmentation (core dumped)".
En fin de compte, PEBKAC pour avoir oublié de définir ulimit, mais le message trompeur m'a fait penser que je devenais folle pendant un moment, me demandant ce qui mangeait mes fichiers de base.
(En outre, en général, la page de manuel core (5) - man 5 core - est une bonne référence pour savoir où votre fichier core se termine et pourquoi il pourrait ne pas être écrit.)
Avec le lancement de systemd , il existe également un autre scénario. Par défaut, systemd stockera les core dumps dans son journal, étant accessible avec la commande systemd-coredumpctl. Défini dans le fichier core_pattern-file:
$ cat /proc/sys/kernel/core_pattern
|/usr/lib/systemd/systemd-coredump %p %u %g %s %t %e
Ce comportement peut être désactivé avec un simple "hack":
$ ln -s /dev/null /etc/sysctl.d/50-coredump.conf
$ sysctl -w kernel.core_pattern=core # or just reboot
Comme toujours, la taille des vidages de mémoire doit être égale ou supérieure à celle du fichier en cours de vidage, comme le fait par exemple ulimit -c unlimited.
Écriture d'instructions pour obtenir un core dump sous Ubuntu 16.04 LTS :
Comme @jtn l'a mentionné dans sa réponse, Ubuntu a délégué l'affichage des plantages à fraction , qui à son tour refuse d'écrire le dump car le programme n'est pas une paquet installé.
![Before making changes]()
Pour remédier à ce problème, nous devons nous assurer que répond écrit les fichiers de vidage principaux pour non-package programmes également. Pour ce faire, créez un fichier nommé ~/.config/apport/settings avec le contenu suivant :
[main] unpackaged=true- Maintenant, bloquez à nouveau votre programme et voyez vos fichiers de blocage générés dans le dossier: /var/crash avec des noms tels que *. 1000.crash . Notez que ces fichiers ne peuvent pas être lus par gdb directement.
![After making changes]()
[Facultatif] Pour rendre les sauvegardes lisibles par gdb, exécutez la commande suivante:
apport-unpack <location_of_report> <target_directory>
Références: Core_dump - Oracle VM VirtualBox
Je pourrais penser à deux possibilités suivantes:
Comme d'autres l'ont déjà souligné, le programme pourrait
chdir(). L'utilisateur qui exécute le programme est-il autorisé à écrire dans le répertoire auquel il est affectéchdir()'? Sinon, il ne peut pas créer le core dump.Pour une raison étrange, le vidage principal n'est pas nommé
core.*Vous pouvez vérifier/proc/sys/kernel/core_patternpour cela. En outre, la commande de recherche que vous avez nommée ne trouverait pas de fichier core dump typique. Vous devez utiliserfind / -name "*core.*", car le nom typique du coredump estcore.$PID
S'il vous manque des vidages de mémoire pour les fichiers binaires sur RHEL et lorsque vous utilisez abrt, assurez-vous que /etc/abrt/abrt-action-save-package-data.conf
contient
ProcessUnpackaged = yes
Cela permet la création de rapports sur les incidents (y compris les vidages de mémoire) pour fichiers binaires ne faisant pas partie des packages installés (construits localement, par exemple).
Mes efforts en WSL ont été infructueux.
Pour ceux qui s'exécutent sur un sous-système Windows pour Linux (WSL), il semble qu'il y ait actuellement un problème en suspens concernant les fichiers de vidage principaux manquants.
Les commentaires indiquent que
Nous sommes au courant de ce problème connu, nous enquêtons sur cela.
Pour Fedora25, je pouvais trouver le fichier core à
/var/spool/abrt/ccpp-2017-02-16-16:36:51-2974/coredump
où ccpp-2017-02-16-16:36:51-2974" is pattern "%s %c %p %u %g %t %P % selon/proc/sys/kernel/core_pattern '
ulimit -c unlimited a fait apparaître correctement le fichier core dans le répertoire actuel après un "core vidé".