Valgrind n'affiche pas les numéros de ligne malgré l'indicateur -g (sur Ubuntu 11.10 / VirtualBox)
Je suis "Learn C the Hard Way", en particulier le chapitre sur Valgrind . Ce chapitre vous donne un programme délibérément erroné pour montrer comment Valgrind fonctionne.
Lorsque j'exécute l'exercice sous Valgrind, je n'obtiens pas de numéro de ligne dans ma trace de pile, juste '(ci-dessous principal)' pour les erreurs.
Je suis certainement compile avec le drapeau -g.
Ma sortie Valgrind est la suivante:
djb@twin:~/projects/Learning/C$ valgrind ./ex4
==5190== Memcheck, a memory error detector
==5190== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==5190== Using Valgrind-3.6.1-Debian and LibVEX; rerun with -h for copyright info
==5190== Command: ./ex4
==5190==
==5190== Use of uninitialised value of size 4
==5190== at 0x4078B2B: _itoa_Word (_itoa.c:195)
==5190== by 0x407CE55: vfprintf (vfprintf.c:1619)
==5190== by 0x40831DE: printf (printf.c:35)
==5190== by 0x4052112: (below main) (libc-start.c:226)
==5190==
==5190== Conditional jump or move depends on uninitialised value(s)
==5190== at 0x4078B33: _itoa_Word (_itoa.c:195)
==5190== by 0x407CE55: vfprintf (vfprintf.c:1619)
==5190== by 0x40831DE: printf (printf.c:35)
==5190== by 0x4052112: (below main) (libc-start.c:226)
==5190==
==5190== Conditional jump or move depends on uninitialised value(s)
==5190== at 0x407CC10: vfprintf (vfprintf.c:1619)
==5190== by 0x40831DE: printf (printf.c:35)
==5190== by 0x4052112: (below main) (libc-start.c:226)
==5190==
==5190== Conditional jump or move depends on uninitialised value(s)
==5190== at 0x407C742: vfprintf (vfprintf.c:1619)
==5190== by 0x40831DE: printf (printf.c:35)
==5190== by 0x4052112: (below main) (libc-start.c:226)
==5190==
I am 0 years old.
I am 68882420 inches tall.
==5190==
==5190== HEAP SUMMARY:
==5190== in use at exit: 0 bytes in 0 blocks
==5190== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==5190==
==5190== All heap blocks were freed -- no leaks are possible
==5190==
==5190== For counts of detected and suppressed errors, rerun with: -v
==5190== Use --track-origins=yes to see where uninitialised values come from
==5190== ERROR SUMMARY: 22 errors from 4 contexts (suppressed: 11 from 6)
J'utilise Ubuntu 11.10 dans une machine virtuelle VirtualBox.
Merci pour toute aide.
Mise à jour
Il semble que si j'appelle une fonction à partir de main() et que cette fonction contient une erreur (par exemple une variable non initialisée), alors je faire obtenir une trace à l'endroit où cette fonction était appelé dans main(). Cependant, les erreurs dans main() restent non spécifiées. Voir cette pâte pour un exemple.
Le résultat que vous avez fourni dans votre question contient la ligne suivante:
==5190== Use --track-origins=yes to see where uninitialised values come from
Par ce message, vous devez exécuter ./ex4 comme ça:
valgrind --track-origins=yes ./ex4
Pour éviter certains problèmes avec Valgrind incapable de trouver les informations de débogage, vous pouvez utiliser la liaison statique:
gcc -static -g -o ex4 ex4.c
La sortie de Valgrind contiendra alors des messages comme Uninitialised value was created by a stack allocation:
==17673== Memcheck, a memory error detector
==17673== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==17673== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==17673== Command: ./ex4
...
==17673== Use of uninitialised value of size 4
==17673== at 0x805CA7B: _itoa_Word (in /home/user/ex4)
==17673== by 0x8049D5F: printf (in /home/user/ex4)
==17673== by 0x8048ECD: main (ex4.c:8)
==17673== Uninitialised value was created by a stack allocation
==17673== at 0x8048EFA: bad_function (ex4.c:17)
...
==17673== Use of uninitialised value of size 4
==17673== at 0x805CA7B: _itoa_Word (in /home/user/ex4)
==17673== by 0x8049D5F: printf (in /home/user/ex4)
==17673== by 0x80490BE: (below main) (in /home/user/ex4)
==17673== Uninitialised value was created by a stack allocation
==17673== at 0x8048EBE: main (ex4.c:4)
...
I am -1094375076 years old.
...
I am -1094369310 inches tall.
...
==17673==
==17673== HEAP SUMMARY:
==17673== in use at exit: 0 bytes in 0 blocks
==17673== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==17673==
==17673== All heap blocks were freed -- no leaks are possible
==17673==
==17673== For counts of detected and suppressed errors, rerun with: -v
==17673== ERROR SUMMARY: 83 errors from 21 contexts (suppressed: 0 from 0)
Fichier ex4.c:
1 #include <stdio.h>
2
3 int main()
4 {
5 int age = 10;
6 int height;
7
8 bad_function();
9
10 printf("I am %d years old.\n");
11 printf("I am %d inches tall.\n", height);
12
13 return 0;
14 }
15
16 int bad_function()
17 {
18 int x;
19 printf("%d\n", x);
20 }
La sortie de Valgrind n'est pas idéale. Il identifie le cadre de pile (fonction) contenant la variable non initialisée, mais il n'imprime pas le nom de la variable.
L'exécution de Linux sous VirtualBox n'a aucun effet sur Valgrind.
Moi aussi, je compilais avec le -g drapeau et toujours pas de numéros de ligne. Après avoir retiré le .dSYM répertoire pour mon application et exécutant valgrind avec le --dsymutil=yes option, j'ai finalement obtenu les numéros de ligne.
Sur de nombreuses distributions, la version par défaut de la glibc ne contient pas de symboles de débogage.
Essayez d'installer le paquet libc6-dbg.
vous devez le compiler avec "-g". gcc -g test.c -o test puis valgrind --track-origins = yes --leak-check = full ./test
Notez que l'exécution de valgrind avec la solution --dsymutil = yes est uniquement pour Mac OS X.
Selon les documents:
--dsymutil= non | oui [non] Cette option n'est pertinente que lors de l'exécution de Valgrind sur Mac OS X.
Mac OS X utilise un schéma de liaison d'informations de débogage différé (debuginfo). Lorsque des fichiers objets contenant debuginfo sont liés dans un .dylib ou un exécutable, le debuginfo n'est pas copié dans le fichier final. Au lieu de cela, le debuginfo doit être lié manuellement en exécutant dsymutil, un utilitaire fourni par le système, sur l'exécutable ou .dylib. Le debuginfo combiné résultant est placé dans un répertoire à côté de l'exécutable ou .dylib, mais avec l'extension .dSYM.
essayez gcc pas cc
cc ne fournit pas les numéros de ligne, mais gcc ne
J'ai chassé ce problème et aucune des autres réponses n'a fonctionné. Ma sortie affichait les symboles corrects, mais les numéros de ligne n'étaient pas présents.
Dans mon cas, cela était dû à la bibliothèque en question utilisant les informations de numéro de ligne compressées .zdebug, et la version de valgrind que j'utilisais était ancienne et n'avait pas encore le patch nécessaire [0].
La solution consistait à mettre à niveau valgrind vers la dernière version.