64 votes

Valgrind n'affiche pas les numéros de ligne malgré le drapeau -g (sur Ubuntu 11.10/VirtualBox)

Je suis 'Learn C the Hard Way', plus précisément le chapitre sur le Valgrind . Ce chapitre vous donne un programme délibérément faux pour montrer comment Valgrind fonctionne.

Lorsque j'exécute l'exercice sous Valgrind, je n'obtiens pas de numéros de ligne dans ma trace de pile, seulement '(below main)' pour les erreurs.

Je suis définitivement compiler avec l'option -g.

Mon résultat de Valgrind est le suivant :

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.

Mise à jour

Il semble que si j'appelle une fonction depuis main() et que cette fonction contient une erreur (par exemple une variable non initialisée), alors je faire obtenir une trace de l'endroit où cette fonction a été appelée main() . Toutefois, les erreurs dans main() restent indéterminés. Voir cette pâte pour un exemple.

58voto

Atom Points 8739

La sortie que vous avez fournie 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 liés à l'incapacité de Valgrind à 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 tels que 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  }

Le rendement de Valgrind n'est pas idéal. 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.

16voto

Jason Denney Points 187

Moi aussi, je compilais avec le -g et je n'obtiens toujours pas de numéros de ligne. Après avoir supprimé le .dSYM pour mon application, et j'ai lancé valgrind avec l'option --dsymutil=yes option, j'ai finalement obtenu les numéros de ligne.

2voto

wilsaj Points 11

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.

2voto

jason Points 21

Utilisiez-vous ubuntu(x86) ? J'ai essayé valgrind sur ubuntu(x64) et il fonctionne parfaitement. Je pense que l'auteur de "learn c the hard way" utilisait aussi valgrind sur une plateforme x64, car son article montre que la taille de int est 8.

1voto

Mujju Points 9

Essayez gcc pas cc

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

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X