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

chaque fois que mon application plante un fichier core dump n'est pas généré. Je me souviens qu'il y a quelques jours, sur un autre serveur, il y avait généré . Je lance l'application en utilisant screen in bash comme ceci:

#!/bin/bash
ulimit -c unlimited
while true; do ./server; done

comme vous pouvez le voir, j'utilise ulimit -c unlimited ce qui est important si je veux générer un dump de noyau, mais il ne le génère toujours pas, quand j'ai un défaut de segmentation. Comment puis-je le faire fonctionner?

46
demandé sur Cyclone 2011-10-12 01:52:57
la source

12 ответов

assurez-vous que votre répertoire courant (au moment du crash -- server peut changer de répertoire) est accessible en écriture. Si le serveur appelle setuid , le répertoire doit être accessible en écriture par l'utilisateur.

vérifier aussi /proc/sys/kernel/core_pattern . Qui peut rediriger le noyau dumps vers un autre répertoire, et que répertoire doit être accessible en écriture. En savoir plus ici .

44
répondu Employed Russian 2011-10-12 04:46:20
la source

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.
50
répondu Philipp Claßen 2013-05-05 04:57:33
la source

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

5
répondu kenorb 2017-05-23 13:31:37
la source

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
3
répondu user18853 2016-05-23 09:16:38
la source

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

3
répondu Seth 2017-09-14 01:02:43
la source

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.

1
répondu chown 2011-10-12 04:49:54
la source

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.

1
répondu Srki Rakic 2016-06-30 20:20:23
la source

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
1
répondu tejus 2016-10-18 18:06:31
la source

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.

0
répondu Brenda J. Butler 2015-11-21 05:06:56
la source

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.

0
répondu user18853 2016-05-05 20:38:10
la source

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.

0
répondu zapstar 2016-08-19 22:56:48
la source

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.

0
répondu Geoff Lentsch 2018-04-25 21:34:58
la source

Autres questions sur