 |
Autres langues Deutsch ; English ; français ; |
| Résumé : Cette page est conçue pour vous aider à collecter des informations pertinentes en cas de plantage d’une application et doit éventuellement être corrigée par vous-même. |
Contents
Prérequis
Tout d’abord, vous devez installer les paquets -debug des applications et toutes les bibliothèques qui pourraient être impliquées. Cela permettra à tous les outils de débogage de rapporter des informations plus pertinentes.
gdb lui-même vous donnera la ligne de commande à exécuter pour installer ces paquets -debug et redémarrer gdb. Vous pouvez maintenant commencer à recueillir des renseignements précieux à l’aide des divers outils ci-dessous.
Pour pouvoir installer les paquets -debug, vous devez ajouter ou activer les dépôts -debug spécifiques. Si vous avez ajouté l’ensemble des dépôts via le gestionnaire de logiciels Mageia, tout ce que vous avez à faire est de les mettre à jour avec la commande suivante dans un terminal en tant que root :
| # urpmi.update --no-ignore debug |
gdb
Le programme gdb est le débogueur standard du projet GNU. Lorsqu’un programme plante à cause d’une erreur de segmentation ou d’une interruption, gdb vous permet d’obtenir une trace de retour, c’est-à-dire de localiser dans le programme le moment où cette erreur a eu lieu.
Exécuter votre application dans gdb
Si vous pouvez reproduire le plantage facilement, alors vous pouvez exécuter votre application dans gdb et obtenir des informations utiles lorsque le plantage se produit.
- Lancez gdb en lui donnant le chemin d’accès à votre application et dites-lui de s’exécuter avec les paramètres, si nécessaire.
- Si vous recevez des messages indiquant le signal 33, vous devez dire à gdb de ne pas les arrêter et de les passer à l’application, puis de les redémarrer :
| Program received signal SIG33, Real-time event 33. [Switching to Thread 1182845264 (LWP 11543)] 0x00002b661d87d536 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 (gdb) handle SIG33 nostop noprint noignore pass Signal Stop Print Pass to program Description SIG33 No No Yes Real-time event 33 (gdb) kill Kill the program being debugged? (y or n) y (gdb) run |
- Lorsque le programme plante, un prompt gdb s’affiche. Récupère la trace d’appels avec la commande
bt full, c’est l’information nécessaire dans le rapport de bogue. Si les messages précédents parlent de threads, vous devriez obtenir toutes les traces d’appels avecthread apply all bt full.
| (gdb) bt full #0 0x00002b526953c7ef in poll () from /lib64/libc.so.6 No symbol table info available. #1 0x00002b52691f412e in g_main_context_iterate (context=0x51f2d0, block=1, dispatch=1, self=Variable "self" is not available.) at gc:2977 max_priority = 2147483647 timeout = 30000 some_ready = Variable "some_ready" is not available. |
Exécuter gdb avec un fichier « core »
Si pour une raison quelconque vous ne pouvez pas facilement reproduire le plantage dans gdb mais que vous avez un fichier « core », vous pouvez faire une analyse post mortem. Par exemple.
| $ gdb /bin/cat core.42 |
puis obtenir la trace d’appels
thread apply all bt full
(Si aucun fichier « core » n’est généré après une erreur de segmentation, essayez d’exécuter ulimit -c unlimited dans le shell à partir duquel vous allez démarrer votre application).
Connecter gdb à une application en cours d’exécution
Le débogage d’applications avec des démarrages complexes, par exemple des services système, peut s’avérer délicat, car vous ne connaissez peut-être pas tous les paramètres utilisés avec le binaire lorsqu’il est lancé.
Dans de tels cas (en supposant que le plantage ne se produise pas au démarrage), vous pouvez connecter gdb à une instance active de l’application.
Tout d’abord, identifiez le processus dans lequel le plantage se produira, par exemple, avec
ps ax | grep //application name//. Si l’application exécute plusieurs processus, essayez de tous les noter et de vérifier syslog pour voir lequel d’entre eux a réellement planté ; quand vous redémarrez l’application, vous pouvez connecter gdb au processus qui occupe la position concernée dans la liste des processus.
Ensuite, connectez gdb au processus en utilisant
gdb executable-name process-id
De cette façon, gdb se connectera à ce processus et le suspendra. Pour reprendre son exécution, utilisez la commande gdb
c command.
Enfin, provoquez le plantage, qui aura pour résultat que gdb vous en informera et affichera un prompt, auquel vous pourrez demander une trace d’appel.
Si vous devez exécuter gdb à partir d’une console tty, dirigez la sortie vers un fichier texte (afin de pouvoir l’attacher à un rapport de bogue plus tard) ; ceci peut être fait en utilisant la commande tee, par exemple :
gdb /bin/cat 2>&1 | tee logfile.txt
Cela sauvegardera toute la sortie dans ce fichier logfile.txt. Lorsque vous aurez terminé, le fichier de sortie contiendra un enregistrement de votre session gdb.
Déboguer Apache dans Mageia 2
Le débogage d’apache est devenu problématique dans Mageia 2. Le script ci-dessous devrait être utile.
| #!/bin/bash # debugging apache got broken with systemd in mga2, it used to be as easy as: # "/etc/rc.d/init.d/httpd stop; /etc/rc.d/init.d/httpd debug" # this script should do the trick. # Oden Eriksson <oeriksson@mandriva.com> /etc/rc.d/init.d/httpd stop defines=`/etc/rc.d/init.d/httpd show_defines` gdb /usr/sbin/httpd --batch --quiet -ex "run -f /etc/httpd/conf/httpd.conf -DNO_DETACH -DONE_PROCESS -DDEBUG $defines" -ex "thread apply all bt full" -ex "quit" |
strace
Le programme strace listera tous les appels système effectués par l’application (ouverture d’un fichier, lecture sur une prise réseau…) et peut vous aider à trouver certains problèmes, comme un fichier manquant, un répertoire non inscriptible, etc.
Vous pouvez l’exécuter avec
strace -f -o \\outputfile\\ \\command\\
Par exemple
strace -f -o ls.strace ls /tmp
lancera ls /tmp et sauvegardera tous les appels système dans le fichier ls.strace
ltrace
valgrind
Lorsqu’un programme est exécuté sous la supervision de Valgrind, toutes les données lues et écrites en mémoire sont vérifiées, et les appels à malloc/new/free/delete sont interceptés. Par conséquent, Valgrind peut détecter des problèmes tels que :
- Utilisation de la mémoire non initialisée
- Mémoire en lecture/écriture une fois libre.
- Lecture/écriture en fin de bloc malloc'd
- Lecture/écriture de zones inappropriées sur la pile
- Fuites de mémoire -- où les pointeurs vers les blocs malloc'd sont perdus à jamais
- Transfert de mémoire non initialisée et/ou non adressable aux appels système
- Utilisation inadaptée de la fonction malloc/new/new [] vs free/delete/delete []
