Fichier de vidage de mémoire n'est pas généré

ce lien contient une bonne liste de vérification pour laquelle les dumps de cœur ne sont pas générés:

• le cœur aurait été plus grand que la limite actuelle.
• vous n'avez pas les permissions nécessaires pour Dumper le noyau (répertoire et fichier). Notez que les dumps de base sont placés dans le répertoire courant du processus de dumping qui pourrait être différent du processus parent.
• vérifier que le système de fichiers est écriture et de disposer de suffisamment d'espace libre.
• si un sous-répertoire nommé core existe dans le répertoire de travail, aucun core ne sera déchargé.
• si un fichier nommé core existe déjà mais a plusieurs liens durs, le noyau ne dumpera pas core.
• vérifier les permissions sur l'exécutable, si l'exécutable a le Suid ou sgid bit activé, les dumps du noyau seront désactivés par défaut. Il en sera de même si vous avez des permissions d'exécution mais pas les autorisations de lecture sur le fichier.
• vérifier que le processus n'a pas changé le répertoire de travail, la limite de taille du cœur, ou le drapeau dumpable.
• certaines versions du noyau ne peuvent pas Dumper des processus avec un espace d'adresse partagé (threads). Les versions plus récentes du noyau peuvent supprimer de tels processus mais ajouteront le pid au nom du fichier.
• l'exécutable peut être dans un format non standard ne supportant pas les dumps core. Chaque format exécutable doit implémenter un noyau la routine du largage.
• la faille de segmentation pourrait en fait être un noyau Oops, vérifiez les journaux système pour tout message Oops.
• l'application appelée exit() au lieu d'utiliser le gestionnaire de vidage du cœur.

Case:

$ sysctl kernel.core_pattern

pour voir comment vos dumps sont créés (%e sera le nom du processus, et %t sera l'heure du système).

si vous avez Ubuntu, vos dumps sont créés par apport dans /var/crash , mais dans un format différent (éditer le fichier pour le voir).

vous pouvez le tester par:

sleep 10 &
killall -SIGSEGV sleep

si le dumping de core est réussi, vous verrez" (core dumped) " après la faille de segmentation indication.

lire la suite:

Comment générer des fichier de vidage de mémoire dans Ubuntu

Ubuntu

s'il vous plaît lire la suite à:

https://wiki.ubuntu.com/Apport

rappelez-vous que si vous démarrez le serveur à partir d'un service , il démarrera une session de bash différente de sorte que l'ulimit ne sera pas efficace là-bas. Essayez de mettre ceci dans votre script lui-même :

ulimit -c unlimited

pour mémoire, sur Debian 9 Stretch ( systemd ), j'ai dû installer le paquet systemd-coredump . Par la suite, des vidages du noyau ont été générés dans le dossier /var/lib/systemd/coredump .

de plus, ces coredumps sont comprimés dans le format lz4 . Pour décompresser, vous pouvez utiliser le paquet liblz4-tool comme ceci: lz4 -d FILE .

pour pouvoir déboguer le coredump décompressé en utilisant gdb , j'ai aussi dû renommer le nom de fichier tout à fait long dans quelque chose de plus court...

vérifiez aussi que vous avez suffisamment d'espace disque sur /var/core ou là où vos dumps de noyau sont écrits. Si la partition est presque pleine ou à 100% d'utilisation du disque, alors ce serait le problème. Mon coeur décharge moyenne quelques concerts donc vous devriez être sûr d'avoir au moins 5-10 gig disponibles sur la partition.

les réponses données ici couvrent assez bien la plupart des scénarios pour lesquels le core dump n'est pas créé. Cependant, dans mon cas, aucun de ces appliquée. Je poste cette réponse comme un complément aux autres réponses.

si votre fichier de base n'est pas créé pour quelque raison que ce soit, je vous recommande de consulter le fichier /var/log/messages. Il pourrait y avoir un indice là-dedans pour expliquer pourquoi le fichier de base n'est pas créé. Dans mon cas, il y avait une ligne indiquant la cause profonde:

Executable '/path/to/executable' doesn't belong to any package

Pour contourner ce problème, modifiez /etc/abrt/abrt-action-save-paquet de données.conf et changer ProcessUnpackaged de " non " en "oui".

ProcessUnpackaged = yes

ce paramètre spécifie s'il faut créer core pour les binaires non installés avec le gestionnaire de paquets.

si l'on est sur une distribution Linux (par exemple CentOS, Debian), alors peut-être que la façon la plus accessible de se renseigner sur les fichiers core et les conditions associées est dans la page de manuel. Il suffit d'exécuter la commande suivante à partir d'un terminal:

man 5 core

bien que ce ne soit pas un problème pour la personne qui a posé la question, parce qu'ils ont exécuté le programme qui devait produire le fichier de base dans un script avec la commande ulimit, j'aimerais documenter que la commande ulimit est spécifique au shell dans lequel vous l'exécutez (comme les variables d'environnement). J'ai passé beaucoup trop de temps à exécuter ulimit et sysctl et des trucs dans un shell, et la commande que je voulais décharger core dans l'autre shell, et me demandant pourquoi le fichier core n'était pas produire.

Je l'ajouterai à mon bashrc. Le sysctl fonctionne pour tous les processus une fois qu'il est émis, mais l'ulimit ne fonctionne que pour le shell dans lequel il est émis (peut - être aussi les descendants) - mais pas pour les autres shell qui fonctionnent.

Note: Si vous avez écrit vous-même un gestionnaire de crash, alors le noyau pourrait ne pas être généré. Alors cherchez le code avec quelque chose sur la ligne:

signal(SIGSEGV, <handler> );

ainsi le SIGSEGV sera manipulé par handler et vous n'obtiendrez pas le vidage du noyau.

si vous appelez daemon () et que vous daemonisez un processus, par défaut le répertoire de travail actuel sera changé en / . Donc, si votre programme est un démon, alors vous devriez chercher un noyau dans le répertoire / et non dans le répertoire du binaire.

au cas où quelqu'un d'autre trébucherait là-dessus. Je vérifiais le code de quelqu'un d'autre - assurez-vous qu'ils ne gèrent pas le signal, afin qu'ils puissent sortir avec élégance. J'ai commenté la manipulation, et j'ai eu le vidage du noyau.