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

À chaque fois, mon plantage de l'application d'un fichier de vidage de mémoire n'est pas généré. Je me souviens il ya quelques jours, sur un autre serveur, il était généré. Je suis de l'exécution de l'application à l'aide de l'écran en bash comme ceci:

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

Comme vous pouvez le voir je suis en utilisant ulimit -c unlimited ce qui est important si je veux générer un core dump, mais elle n'est pas toujours le générer, lorsque j'ai une erreur de segmentation.
Comment puis-je le faire fonctionner?

il ne regarde pas le cas, mais soyez prudent si vous utilisez sudo (et probablement d'autres types de sous-coquille): dans ulimit -c unlimited ; sudo ./server-crashing , la nouvelle limite de ne pas avoir d'effet lorsque server-crashing se bloque.

InformationsquelleAutor Cyclone | 2011-10-11

49

Assurez-vous que votre répertoire actuel (au moment de la collision -- server peut modifier les répertoires) est accessible en écriture. Si le serveur d'appels setuid, le répertoire doit être accessible en écriture par l'utilisateur.

Également vérifier /proc/sys/kernel/core_pattern. Qui peut rediriger les vidages mémoire vers un autre répertoire, et que répertoire doit être accessible en écriture. Plus d'infos ici.
- Oui, core_pattern est délicate. Lorsque Arch Linux passé à systemd, je suis tombé sur ce problème. Maintenant, je suis en utilisant echo "core" > /proc/sys/kernel/core_pattern pour obtenir mon core dumps comme prévu (par défaut, il a été écrit à l'systemd-journal). Vous pouvez passer beaucoup de temps à comprendre ça...
- J'ai besoin d'. C'est ce que j'ai fait trop. Pour comprendre comment faire de l'autre façon est trop dur, je suppose. J'ai essayé, mais je ne pouvais pas.
- Comme une note de côté, cette info est man 5 core page de manuel. Le modèle prend en charge %p et d'autres drapeaux.
InformationsquelleAutor Employed Russian
53

Ce lien contient une liste de vérification pourquoi core dumps ne sont pas générés:
- Le cœur aurait été plus grand que la limite actuelle.
- Vous n'avez pas les autorisations nécessaires pour faire un dump de base (répertoires et fichiers). Notez que core dumps sont placés dans le dumping processus répertoire courant qui peut être différent du processus parent.
- Vérifier que le système de fichier est accessible en écriture et de disposer de suffisamment d'espace libre.
- Si un sous-répertoire nommé core existe pas dans le répertoire de travail pas de noyau sera l'objet de dumping.
- Si un fichier nommé existent déjà, mais dispose de plusieurs liens en dur le noyau ne sera pas de vidage de base.
- Vérifier les autorisations sur le fichier exécutable, si l'exécutable a le suid ou sgid activation du bit core dumps par défaut est désactivé. Le même sera le cas si vous avez les autorisations d'exécution, mais pas les autorisations de lecture sur le fichier.
- Vérifier que le processus n'a pas changé de répertoire de travail, la taille du noyau de limiter ou d'dumpable drapeau.
- Certaines versions du noyau ne peut pas dump processus avec l'espace d'adressage partagé (AKA threads). De plus nouvelles versions de noyau peut générer de tels procédés, mais va ajouter le pid pour le nom de fichier.
- Le fichier exécutable pourrait être dans un format non standard ne supportant pas la core dumps. Chaque format de fichier exécutable doit mettre en œuvre un core dump de routine.
- La faute de segmentation pourrait être un kernel Oops, consulter les journaux système pour toute Oups messages.
- L'application appelée exit() au lieu d'utiliser le core dump gestionnaire.
- Aussi: si l'application définit le gestionnaire de signal pour SIGSEGV, puis sans plus de trucs (voir stackoverflow.com/questions/16697361) core dumps ne sera pas créé.
- Une chose à ajouter: lorsqu'un programme appelle setuid() par exemple, à abandonner les privilèges de root, il n'est plus de base-dumpable (l'exécutable N'a PAS à être suid). Testé sur Linux 3.12 à défaut d'Arch Linux configuration. Je n'ai aucune idée de pourquoi cela se produit, il n'est pas docummented n'importe où. L'appel de prctl(PR_SET_DUMPABLE, 1, ...) après setuid résout ce, il n'est donc pas un système de fichiers de problème d'autorisation.
- En fait, c'est documenté sur le prctl page de man, en vertu de la PR_SET_DUMPABLE l'article: man7.org/linux/man-pages/man2/prctl.2.html
- Le core(5) page de manuel est (je l'espère) la liste officielle sur le pourquoi du core dumps ne sont pas créés.
InformationsquelleAutor Philipp Claßen
5

Vérifier:
```
$ 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 (modifier le fichier pour le voir).

Vous pouvez le tester par:
```
sleep 10 &
killall -SIGSEGV sleep
```
Si de base le dumping est réussie, vous verrez “(core dumped)” après la segmentation d'indication de défaut.

Lire la suite:

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

Ubuntu

Veuillez lire plus:

https://wiki.ubuntu.com/Apport

InformationsquelleAutor kenorb
4

Rappelez-vous, si vous commencez la serveur à partir d'un service, il va commencer un autre bash séance pour que l'espace ne seront pas efficaces. Essayer de mettre cela dans votre script lui-même:
```
ulimit -c unlimited
```
InformationsquelleAutor user18853
3

Pour l'enregistrement, sur Debian 9 Stretch (systemd), j'ai dû installer le package systemd-coredump. Par la suite, core dumps ont été générés dans le dossier /var/lib/systemd/coredump.

En outre, ces les coredumps sont compressés dans le lz4 format. Pour décompresser, vous pouvez utiliser le package liblz4-tool comme ceci: lz4 -d FILE.

Pour être en mesure de déboguer le décompressé coredump à l'aide de gdb, moi aussi j'ai du renommer le complètement de nom de fichier long dans quelque chose de plus court...
- Vous pouvez utiliser la commande coredumpctl list pour voir si core dumps ont été générés.
InformationsquelleAutor Seth
1

Aussi, assurez-vous que vous avez suffisamment d'espace disque sur /var/core ou partout où votre core dumps sont écrites. Si la partition est almos plein ou à 100% de l'utilisation du disque puis que serait le problème. Mon core dumps moyenne, quelques concerts de sorte que vous devez être sûr d'avoir au moins 5 à 10 gig disponible sur la partition.

InformationsquelleAutor chown
1

Les réponses données couvrent assez bien la plupart des scénarios pour lesquels un 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 regarder dans /var/log/messages. Il y a peut être une astuce pour que le coeur de fichier n'est pas créé. Dans mon cas, il y avait une ligne indiquant la cause de racine:
```
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 si de base pour les fichiers binaires n'est pas installé avec le gestionnaire de package.

InformationsquelleAutor Srki Rakic
1

Si vous appelez daemon() et puis daemonize un processus, par défaut, le répertoire de travail actuel va changer pour /. Donc, si votre programme est un démon, alors vous devriez être à la recherche d'un noyau dans / répertoire et non pas dans le répertoire des binaires.

InformationsquelleAutor zapstar
1

Si l'on est sur une distro Linux (par exemple, CentOS, Debian), alors peut-être la manière la plus accessible pour trouver les fichiers de base et les conditions liées à l'est dans la page de man. Il suffit d'exécuter la commande suivante depuis un terminal:
```
man 5 core
```
InformationsquelleAutor tejus
0

Bien que cela ne va pas être un problème pour la personne qui a posé la question, parce que ils ont couru le programme qui était de produire le fichier de base dans un script avec l'aide de la commande ulimit, j'aimerais document que l'espace de commande est spécifique pour le shell dans lequel vous exécutez (variables d'environnement). J'ai passé beaucoup trop de temps à l'exécution de ulimit et sysctl et des trucs dans un shell, et la commande que je voulais dump de base dans l'autre enveloppe, et vous demandez-vous pourquoi le fichier de base n'a pas été produit.

Je vais l'ajouter à mon bashrc. Le sysctl fonctionne pour tous les processus une fois qu'il est publié, mais l'espace ne fonctionne que pour le shell dans lequel il est émis (peut-être aussi les descendants trop), mais pas pour d'autres coquilles qui se trouvent être en cours d'exécution.

InformationsquelleAutor Brenda J. Butler
0

Remarque: Si vous avez écrit des crash handler vous-même, alors le noyau peut pas être générées. Ainsi, la recherche de code avec quelque chose sur la ligne:
```
signal(SIGSEGV, <handler> );
```
donc le SIGSEGV seront traitées par le gestionnaire et vous n'obtiendrez pas le core dump.

InformationsquelleAutor user18853
0

Juste au cas où quelqu'un tombe sur ce. J'étais en train de quelqu'un d'autre code - assurez-vous qu'ils ne sont pas de la manipulation du signal, de sorte qu'ils peuvent arrêter normalement. J'ai commenté la manipulation, et a obtenu le core dump.

InformationsquelleAutor Geoff Lentsch
0

Dans centos,si vous n'êtes pas root compte pour la création de fichier de base:
vous devez être réglé le compte a un privilège root ou connexion compte root:

vim /etc/security/limits.conf

compte cœur tendre illimité
compte noyau dur illimité

alors si vous êtes dans le shell de connexion avec securecrt ou autres:

déconnexion et puis reconnecter

InformationsquelleAutor LuciferJack

Vous devez vous connecter pour publier un commentaire.