Valgrind does not show line numbers despite the -g flag (on Ubuntu 11.10 / VirtualBox)

Question

I follow the “Learn C the Hard Way”, specifically in the chapter on Valgrind . In this chapter, you are deliberately mistaken to show how Valgrind works.

When I run the exercise under Valgrind, I do not get the line numbers in the stack trace, just "(below the main)" for errors.

I am definitely compiling with the -g flag.

The output of My Valgrind is as follows:

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) 

I am using Ubuntu 11.10 in a virtual virtual machine.

Thanks for any help.

Update

It seems that if I call a function from main() , and this function contains an error (for example, an uninitialized variable), then I get a trace to the place where the function was called in main() . However, errors inside main() remain undefined. See this insert for an example.

Answer 1

The result you provided in your question contains the following line:

 ==5190== Use --track-origins=yes to see where uninitialised values come from 

For this message, you should run ./ex4 as follows:

 valgrind --track-origins=yes ./ex4 

To avoid some problems so that Valgrind cannot find debugging information, you can use static binding:

 gcc -static -g -o ex4 ex4.c 

Valgrind output will contain messages of type 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) 

ex4.c file:

  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 } 

Valgrind's output is not perfect. It identifies the frame (function) of the stack containing the uninitialized variable, but does not print the variable name.

Running Linux under VirtualBox does not affect Valgrind.

Answer 2

I also compiled with the -g flag and still did not get line numbers. After deleting the .dSYM directory for my application and running valgrind with the option --dsymutil=yes , I finally got the line numbers.

Answer 3

On many distros, the default version of glibc does not contain debugging symbols.

Try installing the libc6-dbg package.

Answer 4

you must compile it with "-g". gcc -g test.c -o test and then valgrind --track-originins = yes --leak-check = full./test

Answer 5

Note that running valgrind with the --dsymutil = yes solution is only for Mac OS X.

According to the docs:

- dsymutil = no | yes [no] This option is only applicable when running Valgrind on Mac OS X.

Mac OS X uses a deferred information binding scheme (debuginfo). When the object files containing debuginfo are associated with a .dylib or executable file, debuginfo is not copied to the final file. Instead, debuginfo must be linked manually by running dsymutil, a system utility, on an executable or .dylib file. The resulting combined debuginfo is placed in the directory with the executable or .dylib, but with the extension .dSYM.

Answer 6

try gcc not cc

cc does not provide line numbers, but gcc does

Answer 7

I pursued this problem and none of the other answers worked. My output displayed the correct characters, but line numbers were not present.

In my case, this was due to the library in question using .zdebug information on the number of compressed lines, and the version of valgrind that I used was old and did not yet have the necessary patch [0].

The solution was updating valgrind to the latest version.

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