core dumped - mais le fichier core n'est pas dans le répertoire actuel?

Sur Ubuntu récent (12.04 dans mon cas), il est possible que "Segmentation fault (Core dumped)" soit imprimé, mais aucun fichier core produit 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 n'avez pas fait ulimit -c unlimited) - c'est la valeur par défaut sur Ubuntu. Normalement, cela supprimerait le " (Core dumped)", vous cluing dans votre erreur, mais sur Ubuntu, les corefiles sont acheminés vers Apport (plantage D'Ubuntu système de déclaration) via /proc/sys/kernel/core_pattern, et cela semble provoquer le message trompeur.

Si Apport découvre que le programme en question n'en est pas un, il devrait signaler des plantages (ce que vous pouvez voir se produire dans /var/log/apport.log), Il revient à simuler le comportement du noyau par défaut de mettre un fichier core dans le cwd (ceci est fait dans le script /usr/share/apport/apport). Cela inclut le respect de l'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é à apporter), d'où le message " Segmentation fault (Core dumped)".

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

(aussi, en général, la page de manuel core(5) -- man 5 core -- est une bonne référence pour l'endroit où votre fichier core finit et les raisons pour lesquelles il pourrait ne pas être écrit.)

Avec le lancement de systemd , Il y a aussi un autre scénario. Par défaut, systemd stockera les vidages de base dans son journal, étant accessible avec la commande systemd-coredumpctl. 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 vidages de noyau doit être égale ou supérieure à la taille du noyau qui est en cours de vidage, comme par exemple ulimit -c unlimited.

Écrire des instructions pour obtenir un vidage de base sous Ubuntu 16.04 LTS :

1. Comme @jtn l'a mentionné dans sa réponse, Ubuntu délègue l'affichage des plantages à apport , qui refuse à son tour d'écrire le dump car le programme n'est pas un paquet installé.

2. Pour remédier au problème, nous devons nous assurer que apport écrit également des fichiers de vidage de base pour les programmes non-package. Pour ce faire, créez un fichier nommé ~/.config/apport/paramètres avec le contenu suivant:
   [main] unpackaged=true

3. Maintenant plantez à nouveau votre programme, et voyez vos fichiers de plantage 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.

4. [facultatif] pour rendre les vidages lisibles par gdb, exécutez ce qui suit commande:

   apport-unpack <location_of_report> <target_directory>

Références: Core_dump-Oracle VM VirtualBox

Je pourrais penser à deux possibilités suivantes:

1. Comme d'autres l'ont déjà souligné, le programme peut - chdir(). L'utilisateur exécutant le programme est-il autorisé à écrire dans le répertoire dans lequel il chdir()'ed? Sinon, il ne peut pas créer le vidage de base.

2. Pour une raison étrange, le vidage de base n'est pas nommé core.* Vous pouvez vérifier /proc/sys/kernel/core_pattern pour cela. En outre, la commande find que vous avez nommée ne trouverait pas de vidage de base typique. Vous devez utiliser find / -name "*core.*", comme le nom typique du coredump est core.$PID

Si vous manquez des vidages de base pour les binaires sur RHEL et lors de l'utilisation de abrt, assurez-vous que /etc/abrt/abrt-action-save-package-data.conf

Contient

ProcessUnpackaged = yes

Cela permet la création de rapports de plantage (y compris les vidages de base) pour les binaires qui ne font pas partie des paquets installés (par exemple construits localement).

Pour fedora25, j'ai pu trouver le fichier de base à

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

Mes efforts dans WSL ont échoué.

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 base manquants.

Les commentaires indiquent que

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

Problème Github

Commentaires Des Développeurs Windows