Le noyau est vidé, mais le fichier du noyau ne se trouve pas dans le répertoire actuel ?

Question

Pendant l'exécution d'un programme C, il est dit "(core dumped)" mais je ne vois pas de fichiers sous le chemin actuel.

J'ai défini et vérifié le ulimit :

ulimit -c unlimited 
ulimit -a 

J'ai aussi essayé de trouver un fichier nommé "core", mais je n'ai pas obtenu le fichier core dumped ?
Une aide quelconque, où se trouve mon fichier de base ?

Answer 1

Lire /usr/src/linux/Documentation/sysctl/kernel.txt .

core_pattern est utilisé pour spécifier un nom de modèle de fichier de vidage de noyau.

• Si le premier caractère du modèle est un '|', le noyau traitera le reste du le reste du motif comme une commande à exécuter. Le core dump sera écrit dans l'entrée standard de ce programme au lieu d'un fichier.

Au lieu d'écrire le vidage du noyau sur le disque, votre système est configuré de manière à l'envoyer à l'adresse suivante abrt (ce qui signifie : Outil automatisé de signalement des bogues, no "avorter") à la place. Outil automatisé de signalement des bogues n'est peut-être pas aussi documentée qu'elle debe être...

Dans tous les cas, la réponse rapide est que vous devriez être en mesure de trouver votre fichier principal dans /var/cache/abrt , donde abrt le stocke après avoir été invoqué. De même, d'autres systèmes utilisant Apport peut mettre à l'abri des noyaux dans /var/crash et ainsi de suite.

Answer 2

Sur une Ubuntu récente (12.04 dans mon cas), il est possible que le message "Segmentation fault (core dumped)" soit affiché, mais aucun fichier core n'est produit là où l'on pourrait s'y attendre (par exemple pour un programme compilé localement).

Cela peut se produire si vous avez un ulimit de taille de fichier de base de 0 (vous n'avez pas fait ulimit -c unlimited ) -- c'est la valeur par défaut sur Ubuntu. Normalement, cela devrait supprimer le "(core dumped)", vous indiquant votre erreur, mais sur Ubuntu, les corefiles sont envoyés à Apport (le système de rapport de crash d'Ubuntu) via /proc/sys/kernel/core_pattern et cela semble être à l'origine du message trompeur.

Si Apport découvre que le programme en question n'est pas celui pour lequel il devrait signaler les plantages (ce que vous pouvez voir se produire en /var/log/apport.log ), il se rabat sur la simulation du comportement par défaut du noyau qui consiste à mettre un fichier de base dans le cwd (ceci est fait dans le script. /usr/share/apport/apport ). Cela inclut le respect de ulimit, auquel cas il ne fait rien. Mais (je suppose) qu'en ce qui concerne le noyau, un corefile a été généré (et envoyé à apport), d'où le message "Segmentation fault (core dumped)".

Finalement, PEBKAC a oublié de définir ulimit, mais le message trompeur m'a fait penser que je devenais fou pendant un moment, me demandant ce qui mangeait mes corefiles.

(De même, en général, la page de manuel core(5) -- man 5 core -- est une bonne référence pour savoir où se trouve votre fichier de base et les raisons pour lesquelles il pourrait ne pas être écrit).

Answer 3

Avec le lancement de systemd il y a aussi un autre scénario. Par défaut, systemd stocke les vidages de noyau dans son journal, accessible avec la commande systemd-coredumpctl commandement. Défini dans le fichier core_pattern :

$ cat /proc/sys/kernel/core_pattern 
|/usr/lib/systemd/systemd-coredump %p %u %g %s %t %e

Le moyen le plus simple de vérifier les vidanges de noyau stocké est de le faire via coredumpctl list (les anciens core dumps peuvent avoir été supprimés automatiquement). Ce comportement peut être désactivé par 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 noyau doit être égale ou supérieure à la taille du noyau qui est vidé, comme par exemple ulimit -c unlimited .

Answer 4

Je pense à deux possibilités :

1. Comme d'autres l'ont déjà souligné, le programme pourrait chdir() . L'utilisateur qui exécute le programme a-t-il le droit d'écrire dans le répertoire où il se trouve ? chdir() pour ? Si non, il ne peut pas créer le core dump.

2. Pour une raison étrange, le fichier de base n'est pas nommé. core.* Vous pouvez vérifier /proc/sys/kernel/core_pattern pour cela. De plus, la commande find que vous avez nommée ne trouvera pas un core dump typique. Vous devriez utiliser find / -name "*core.*" car le nom typique du corédump est core.$PID

Answer 5

Faites un ls -lrt dans le répertoire juste après que le noyau soit vidé. Le dernier fichier listé est généralement le fichier de base.