Discussion :

[piemur2000]

Bonjour,

Mon appli crash après deux ou trois jours de fonctionnement. Je cherche à obtenir plus d'information sur d'informations sur les raisons de ce crash. Existe t'il des moyen d'obtenir la call stack lors d'un segfault par exemple? Connaissez vous un moyen de de générer un rapport d'erreur au moment du crash?
Je travaille avec g++ sous linux. J'ai utilisé valgrind pour essayer de détecter des memory leak possible mais n'en ai trouvé aucun. Cela semble confirmé par le fait que l'utilisation mémoire du programme est stable.

Merci

[Obsidian]

Normalement, une segfault déclenche le dump d'un fichier « core », qui sert précisément à tout cela. Toutefois, sur les systèmes personnels, la taille maximum de ce fichier est ramenée à zéro, désactivant la production de ce fichier, pour éviter que de nombreux « core » encombre le disque d'un utilisateur qui ne sait pas ce que c'est. Fais

Code Shell :

Sélectionner tout - Visualiser dans une fenêtre à part

ulimit -c unlimited

… pour que ces fichiers soient de nouveau produits, relance ton programme depuis le shell où tu as saisi cette commande et attends qu'il plante.

Tu pourras ensuite ouvrir le debugger en faisant « gdb nomdufichiercore nomdetonexecutable » et retrouver l'environnement de runtime au moment du crash. Fais ensuite « bt » pour avoir la pile des appels.

[Davidbrcz]

Normalement, une segfault déclenche le dump d'un fichier « core », qui sert précisément à tout cela. Toutefois, sur les systèmes personnels, la taille maximum de ce fichier est ramenée à zéro, désactivant la production de ce fichier, pour éviter que de nombreux « core » encombre le disque d'un utilisateur qui ne sait pas ce que c'est. Fais

Code Shell :
ulimit -c unlimited


… pour que ces fichiers soient de nouveau produits, relance ton programme depuis le shell où tu as saisi cette commande et attends qu'il plante.

Tu pourras ensuite ouvrir le debugger en faisant « gdb nomdufichiercore nomdetonexecutable » et retrouver l'environnement de runtime au moment du crash. Fais ensuite « bt » pour avoir la pile des appels.

Euh, je ne connais pas cette technique mais mon man m'indique qu'elle est obsolète, étrange.

Avec ma debian, pour avoir accès au core dump, il faut avoir préalablement compilé en débug avec -g et juste lancer l'éxecutable.

[bruno_pages]

Bonsoir,

au moins avant ulimit déterminait bien la taille max du core produit, mais comme ma Suse commence à dater je ne peux pas tester si cela à changer ou non

par contre un core sera produit même si la compilation est faite sans -g, mais le core sera juste inutilisable

mais pourquoi ne pas simplement lancer l'exécution sous debugger et attendre le crash ?

une exécution sous valgrind est très ralenti, s'il faut attendre 2 ou 3 jour en temps normal il faudra sans doute attendre plus de 3 semaines sous valgrind.

pourquoi cherchez-vous les memory leak, vous explosez la mémoire ? notez qu'on peut aussi exploser la mémoire sans memory leak (string s; for(;; ) s += "miam miam";). En tout cas si vous explosez la mémoire vous n'aurez pas de core (cela prend de la mémoire pour être fait)

[piemur2000]

Normalement, une segfault déclenche le dump d'un fichier « core », qui sert précisément à tout cela. Toutefois, sur les systèmes personnels, la taille maximum de ce fichier est ramenée à zéro, désactivant la production de ce fichier, pour éviter que de nombreux « core » encombre le disque d'un utilisateur qui ne sait pas ce que c'est. Fais

Code Shell :

Sélectionner tout - Visualiser dans une fenêtre à part

ulimit -c unlimited

… pour que ces fichiers soient de nouveau produits, relance ton programme depuis le shell où tu as saisi cette commande et attends qu'il plante.

Tu pourras ensuite ouvrir le debugger en faisant « gdb nomdufichiercore nomdetonexecutable » et retrouver l'environnement de runtime au moment du crash. Fais ensuite « bt » pour avoir la pile des appels.

En effet, lorsque je développe sous Ubuntu 9.10 je peux générer des fichier "core" en cas de segfault. Pour cela il faut definir la taille des fichier "core" et activer apport :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
ulimit -c unlimited
sudo service apport start force_start=1

Cependant mon application est aussi développé pour un système linux embarqué ou le kernel ne permet pas la génération de fichiers "core". Je me demandais donc s'il était possible par un moyen quelconque de générer un rapport d'erreur juste avant de quitter l'application. Pour l'instant j'intercepte juste le signal SIGSEGV pour logguer un message avant de quitter l'application en cas de segfault.

pourquoi cherchez-vous les memory leak, vous explosez la mémoire ?

J'ai justement cherché les memory leak pour vérifier que je n'explosais pas la mémoire. En parallèle je vérifie régulièrement la mémoire utilisée avec top.

[bruno_pages]

pour prendre tout les cas de crash il faut traiter non seulement SIGSEGV mais aussi SIGBUS, SIGILL, SIGFPE et SIGXCPU et ce traitement peut être :

• la production d'un core via l'utiilsation de gcore, si votre kernel le permet
• ou la production manuelle de la pile du thread où l'erreur c'est produit via la fonction backtrace, cela donne moins d'info qu'un core, mais vous savez quand même où l'erreur c'est produite et le contexte d'appel

[piemur2000]

pour prendre tout les cas de crash il faut traiter non seulement SIGSEGV mais aussi SIGBUS, SIGILL, SIGFPE et SIGXCPU et ce traitement peut être :

• la production d'un core via l'utiilsation de gcore, si votre kernel le permet
• ou la production manuelle de la pile du thread où l'erreur c'est produit via la fonction backtrace, cela donne moins d'info qu'un core, mais vous savez quand même où l'erreur c'est produite et le contexte d'appel

Merci pour l'information. Malheureusement la fonction backtrace n'est pas disponible sur mon linux embarqué. Pour l'instant je me suis contenté de logger les différents signaux avant de quitter mon application. J'ai aussi ajouté la fonction, le fichier et le numéro de ligne dans le constructeur de mes exceptions (via une macro qui fait ça automatiquement). J'ai aussi créé une exception UnexpectedException que je fais remonter de fonction en fonction au lieu d'utiliser std::set_terminate qui ne donne aucune information sur l'exception en question.