Valgrind ne montre pas les numéros de ligne malgré l’option -g (sous Ubuntu 11.10 / VirtualBox)

Je suis en train d’apprendre «Apprenez la manière difficile», en particulier le chapitre sur Valgrind . Ce chapitre vous donne un programme délibérément erroné pour montrer comment Valgrind fonctionne.

Lorsque je lance l’exercice sous Valgrind, je n’obtiens pas de numéros de ligne dans ma trace de stack, juste «(en dessous de la ligne principale)» pour les erreurs.

Je comstack définitivement 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 VM VirtualBox.

Merci pour toute aide.

Mettre à jour

Il semble que si j’appelle une fonction de main() et que cette fonction contienne une erreur (par exemple une variable non initialisée), alors j’obtiens une trace à l’endroit où cette fonction a été appelée dans main() . Cependant, les erreurs dans main() restnt indéterminé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 ceci:

 valgrind --track-origins=yes ./ex4 

Pour éviter certains problèmes avec Valgrind incapable de trouver des 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 la 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  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 la stack (fonction) contenant la variable non initialisée, mais 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 drapeau -g et n’obtenais toujours pas de numéros de ligne. Après avoir supprimé le répertoire .dSYM de mon application et exécuté valgrind avec l’option --dsymutil=yes , j’ai finalement obtenu des numéros de ligne.

Sur de nombreuses dissortingbutions, la version par défaut de glibc ne contient pas de symboles de débogage.

Essayez d’installer le paquet libc6-dbg.

essayez gcc pas cc

cc ne fournit pas les numéros de ligne, mais gcc le fait

vous devriez le comstackr avec “-g”. gcc -g test.c -o test et valgrind –track-origins = yes –leak-check = full ./test

Notez que l’exécution de valgrind avec la solution –dsymutil = yes ne concerne que Mac OS X.

Selon les documents:

dsymutil = no | yes [non] Cette option n’est pertinente que si vous exécutez Valgrind sous Mac OS X.

Mac OS X utilise un schéma de liaison des informations de débogage différé (debuginfo). Lorsque des fichiers d’objects contenant debuginfo sont liés dans un fichier .dylib ou un exécutable, les informations de débogage ne sont pas copiées 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 de .dylib, mais avec l’extension .dSYM.

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, c’était dû à la bibliothèque en question en utilisant .zdebug compressé des informations de numéro de ligne, et la version de valgrind que j’utilisais était ancienne et n’avait pas encore le correctif nécessaire [0].

La solution consistait à mettre à niveau valgrind vers la dernière version.

[0] https://bugs.kde.org/show_bug.cgi?id=303877