Noyau vidé, mais le fichier principal n'est pas dans le répertoire actuel?

277

Lors de l'exécution d'un programme C, il dit "(core dumped)" mais je ne vois aucun fichier sous le chemin actuel.

J'ai défini et vérifié les 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 dumpé?
Toute aide, où est mon fichier principal?

c linux coredump

— webminal.org
source

1

Le programme appelle-t-il chdir à un moment donné? Si oui, regardez là-bas.

— William Pursell

2

Le programme change-t-il son répertoire de travail? Regardez là.

— Richard Pennington

Je rechercherais tout le disque dur pour un fichier récent;)

— Hamish Grubijan

1

oups non, ce n'est pas là ... Je l'ai vérifié .. programme chdir vers / mnt et / i vérifié les deux répertoires mais n'a pas pu trouver le fichier. J'ai même trouvé / -name "* core". même cela ne m'a pas montré le fichier. Le programme utilise C + sqlite, tout en insérant des valeurs qu'il vide. Il dit erreur d'assertion == 0 pour la première fois et erreur = 101 pour la deuxième fois ..

— webminal.org

8

Oui, si vous remplacez /proc/sys/kernel/core_patternpar une chaîne commençant par, /tmpc'est là que vos vidages de mémoire iront.

— éphémère

240

Lisez /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 vidage principal.

Si le premier caractère du modèle est un «|», le noyau traitera le reste du modèle comme une commande à exécuter. Le vidage de mémoire sera écrit dans l'entrée standard de ce programme plutôt que dans un fichier.

Au lieu d'écrire le vidage de mémoire sur le disque, votre système est configuré pour l'envoyer au abrtprogramme à la place. L'outil de rapport de bogue automatisé n'est peut-être pas aussi documenté qu'il devrait l' être ...

Dans tous les cas, la réponse rapide est que vous devriez pouvoir trouver votre fichier principal dans /var/cache/abrt, où le abrtstocke après avoir été appelé. De même, d'autres systèmes utilisant Apport peuvent écarter les cœurs /var/crash, etc.

— éphémère
source

30

oui, j'ai édité core_pattern avec le contenu suivant echo "core.% e.% p"> / proc / sys / kernel / core_pattern .. maintenant il crée le fichier de vidage de mémoire dans le répertoire actuel lui-même. avec le nom "core.giis.12344" etc. Merci à tous pour vos réponses / commentaires / astuces.

— webminal.org

20

Juste pour noter que le programme fedora 18 abrt stocke les vidages mémoire au /var/spool/abrt/lieu de/var/cache/abrt

— Nelson

4

Existe-t-il un moyen de permettre aux utilisateurs de configurer cela pour eux-mêmes, plutôt que tout le monde doive utiliser la configuration du système?

— allyourcode

Lorsque cette commande est exécutée et que le processus est invoqué, stdout et stderr ne sont-ils pas ouverts par défaut? Je vois des choses très étranges se produire. lorsque j'utilise dup2 de stderr et stdout dans mon fichier personnalisé (applog.txt), les données que j'écris dans un autre fichier (mycore.BIN) sont redirigées vers un fichier que j'ai utilisé pour attraper stdout & stderr (applog.txt) . Y a-t-il une bonne lecture sur celui-ci? Veuillez suggérer. Merci

— mk ..

20

systemd dans le magasin archlinux coredumps à/var/lib/systemd/coredump/

— Francois

224

Sur Ubuntu récent (12.04 dans mon cas), il est possible d'imprimer "Erreur de segmentation (core dumped)", mais aucun fichier core produit là où vous pourriez vous en attendre (par exemple pour un programme compilé localement).

Cela peut se produire si vous avez une taille de fichier de base ulimit de 0 (vous ne l'avez pas fait ulimit -c unlimited) - c'est la valeur par défaut sur Ubuntu. Normalement, cela supprimerait le "(core dumped)", vous informant de votre erreur, mais sur Ubuntu, les corefiles sont dirigés vers Apport (le système de rapport de crash d'Ubuntu) via /proc/sys/kernel/core_pattern, et cela semble provoquer le message trompeur.

Si Apport découvre que le programme en question n'en fait pas partie, il devrait signaler des plantages (que vous pouvez voir se produire dans /var/log/apport.log), il revient à simuler le comportement par défaut du noyau consistant à placer un fichier core dans le cwd (cela se fait dans le script /usr/share/apport/apport). Cela inclut d'honorer 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 répartir), d'où le message "Erreur de 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 fou pendant un moment, me demandant ce qui mangeait mes corefiles.

(De plus, 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 core et pourquoi il peut ne pas être écrit.)

— jtn
source

4

Merci beaucoup - j'ai rencontré le même problème. Btw, Ubuntu 14.04 présente exactement le même comportement que celui que vous avez décrit.

— Malte Skoruppa du

5

Sur mon installation Ubuntu (modifiée le 14.04), il existe une solution de contournement temporaire facile pour cela en exécutant sudo service apport stop--- après avoir exécuté cela, il est passé /proc/sys/kernel/core_patterndu tube de répartition à juste core. Apport est assez intelligent pour réparer core_patterntemporairement, je suppose.

— Patrick Collins

6

"ulimit -c unlimited" est exactement ce dont j'avais besoin - Merci!

— Dave C

4

J'ai essayé toutes les réponses applicables, et chaque emplacement dans chaque commentaire ici après avoir fait la commande ulimit, mais je ne trouve toujours pas de fichier de base n'importe où sur mon Ubuntu 16.04 LTS ...

— Nagev

2

@ElectricGoat Non, je ne l'ai pas fait. C'est une mauvaise conception UX, OMI. Le système doit simplement imprimer le chemin, ou ne pas imprimer de message du tout s'il n'est pas en cours de création. J'ajouterai ma propre réponse, quand ou si j'aurai l'occasion d'enquêter davantage.

— Nagev

80

Avec le lancement de systemd , il existe également un autre scénario. Par défaut, systemd stockera les vidages mémoire dans son journal, accessible avec la systemd-coredumpctlcommande. Défini dans le fichier core_pattern:

$ 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 core dumps doit être égale ou supérieure à la taille du core en cours de dumping, comme par exemple ulimit -c unlimited.

— timss
source

Ce "hack" n'a pas fonctionné pour moi (même après un redémarrage). J'utilise Arch Linux et j'ai déjà exécuté ulimit -c unlimited.

— gsingh2011

@ gsingh2011 Il est peut-être obsolète. Je ne lance plus Arch, donc je ne peux pas dire si cela devrait fonctionner de nos jours. Si vous le comprenez, n'hésitez pas à me / nous mettre à jour avec un nouveau commentaire.

— timss

5

@ gsingh2011 Essayez 50-coredump.confau lieu de coredump.conf. Cela devrait l'emporter /lib/sysctl.d/50-coredump.conf. La valeur par défaut peut être restaurée avecsysctl -w kernel.core_pattern=core

— Lekensteyn

J'ai dû désactiver l'appport pour que cela fonctionnesudo service apport stop

— rahul003

51

Écriture d'instructions pour obtenir un vidage de mémoire sous Ubuntu 16.04 LTS :

Comme @jtn l'a mentionné dans sa réponse, Ubuntu délègue l'affichage des plantages à répartir , qui à son tour refuse d'écrire le vidage car le programme n'est pas un package installé.
Pour résoudre le problème, nous devons également nous assurer que répart écrit également les fichiers de vidage de mémoire pour les programmes autres que les packages . Pour ce faire, créez un fichier nommé ~ / .config / répart / settings avec le contenu suivant:
[main] unpackaged=true
Maintenant, plantez à nouveau votre programme et voyez vos fichiers de crash générés dans le dossier: / var / crash avec des noms comme * .1000.crash . Notez que ces fichiers ne peuvent pas être lus directement par gdb .
[Facultatif] Pour rendre les vidages lisibles par gdb, exécutez la commande suivante:

apport-unpack <location_of_report> <target_directory>

Références: Core_dump - Oracle VM VirtualBox

— ankurrc
source

3

C'est la seule solution qui a fonctionné pour moi dans Ubuntu 18.04

— greuze

À quel utilisateur ~ / appartient-il? Si le processus est exécuté par root, cela signifie-t-il /root/.config/apport/settings?

— Nicholi

@Nicholi Je pense que ce devrait être l'utilisateur qui a exécuté le programme. Je ne suis pas sûr cependant.

— ankurrc

12

Je pourrais penser à deux possibilités suivantes:

Comme d'autres l'ont déjà souligné, le programme pourrait chdir(). L'utilisateur exécutant le programme est-il autorisé à écrire dans le répertoire dans lequel il chdir()est édité? Sinon, il ne peut pas créer le vidage de mémoire.
Pour une raison étrange, le vidage de mémoire n'est pas nommé. core.*Vous pouvez le vérifier /proc/sys/kernel/core_pattern. De plus, la commande find que vous avez nommée ne trouverait pas de vidage de mémoire typique. Vous devez utiliser find / -name "*core.*", car le nom typique du coredump estcore.$PID

— ahans
source

voici mon modèle - cela signifie-t-il que le fichier core est nommé quelque chose comme "PID.signal.userid" au lieu de core.pid ??? $ cat / proc / sys / kernel / core_pattern / usr / lib / hookCCpp / var / char / abrt% p% s% u

— webminal.org

9

Si vous manquez des vidages de mémoire pour les binaires sur RHELet lors de l'utilisation abrt, assurez-vous que/etc/abrt/abrt-action-save-package-data.conf

contient

ProcessUnpackaged = yes

Cela permet la création de rapports d'erreur (y compris les vidages de mémoire) pour les binaires qui ne font pas partie des packages installés (par exemple, construits localement).

— MRalwasser
source

6

Pour fedora25, j'ai pu trouver le fichier core sur

/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 '

— mahaveer darade
source

5

Mes efforts en WSL ont été infructueux.

Pour ceux qui s'exécutent sur le sous-système Windows pour Linux (WSL), il semble y avoir un problème ouvert en ce moment pour les fichiers de vidage de mémoire manquants.

Les commentaires indiquent que

C'est un problème connu dont nous sommes conscients, c'est quelque chose que nous étudions.

Problème avec Github

Commentaires des développeurs Windows

— Brandon Søren Culley
source

5

Dans Ubuntu18.04, la façon la plus simple d'obtenir un fichier core est de saisir la commande ci-dessous pour arrêter le service d'allocation.

sudo service apport stop

Réexécutez ensuite l'application, vous obtiendrez le fichier de vidage dans le répertoire actuel.

— Nicolas Gong
source

3

Je suis sur Linux Mint 19 (basé sur Ubuntu 18). Je voulais avoir des coredumpfichiers dans le dossier actuel. J'ai dû faire deux choses:

Changement /proc/sys/kernel/core_pattern(par # echo "core.%p.%s.%c.%d.%P > /proc/sys/kernel/core_patternou par# sysctl -w kernel.core_pattern=core.%p.%s.%c.%d.%P)
Augmenter la limite de taille de fichier de base de $ ulimit -c unlimited

Cela était déjà écrit dans les réponses, mais j'ai écrit pour résumer succinctement. La modification intéressante de la limite ne nécessitait pas de privilèges root (selon /ubuntu/162229/how-do-i-increase-the-open-files-limit-for-a-non-root-user non- root ne peut que baisser la limite, ce qui était inattendu - les commentaires à ce sujet sont les bienvenus).

— Marisha
source

2

ulimit -c unlimited fait apparaître correctement le fichier core dans le répertoire courant après un "core dumped".

— Nicolas VERHELST
source