Don't see line numbers using Valgrind inside Ubuntu (Vagrant+Virtualbox)

Question

I am currently reading and fallowing along the "Learn C The Hard Way"-book. On exercise 4 I have to install Valgrind. I first did this locally on my Macbook running Maverick, but I received a warning that Valgrind might not work 100%.

So now I tried it with Vagrant (using VirtualBox) with an Ubuntu 12.04 box. You can check out the exact Vagrantfile (setup) and the exercise files here on my github repo.

The problem:
I don't see the line numbers and instead I get something like 0x40052B.

I compiled the files by doing the fallowing:

$ make clean # Just to be sure
$ make
$ valgrind --track-origins=yes ./ex4

I pasted the result to pastebin here.

I found the fallowing 3 questions on SO that (partly) describes the same problem, but the answer's and there solutions didn't work for me:

• Valgrind not showing line numbers in spite of -g flag (on Ubuntu 11.10/VirtualBox)
• How do you get Valgrind to show line errors?
• Valgrind does not show line-numbers

What I have tried sofar:

• Added libc6-dbg
• installed gcc and tried compiling with that instead of cc.
• added --track-origins=yes to the valgrind-command
• Added (and later removed) compiling with -static and -oO flags

So I am not sure where to go from here? I could try and install the latest (instead of v3.7) off gcc manually although that looked rather difficult.

edit:
@abligh answer seems to be right. I made this with kaleidoscope: On the left side you see the result of: valgrind --track-origins=yes ./ex4 and on the right side the result of valgrind ./ex4.

I guess I still need to learn allot about c and it's tools.

Answer 1

I think you are just missing them in the output.

Here is some of your output (copied from Pastebin):

==16314==    by 0x40052B: main (ex4.c:9)
                                     ^^--- LINE NUMBER
==16314==  Uninitialised value was created by a stack allocation
==16314==    at 0x4004F4: main (ex4.c:4)
                                     ^^--- LINE NUMBER

Though I think your invocation is wrong to check memory leaks. I wrote a very simple program to leak one item:

#include <stdio.h>
#include <stdlib.h>

int
main (int argc, char **argv)
{
  void *leak;
  leak = malloc (1);
  printf ("Leaked %p\n", leak);
  exit (0);
}

and compiled it using your Makefile:

gcc -Wall -g    test.c   -o test

Running your command:

$ valgrind --track-origins=yes ./test
==26506== Memcheck, a memory error detector
==26506== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==26506== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==26506== Command: ./test
==26506== 
Leaked 0x51f2040
==26506== 
==26506== HEAP SUMMARY:
==26506==     in use at exit: 1 bytes in 1 blocks
==26506==   total heap usage: 1 allocs, 0 frees, 1 bytes allocated
==26506== 
==26506== LEAK SUMMARY:
==26506==    definitely lost: 0 bytes in 0 blocks
==26506==    indirectly lost: 0 bytes in 0 blocks
==26506==      possibly lost: 0 bytes in 0 blocks
==26506==    still reachable: 1 bytes in 1 blocks
==26506==         suppressed: 0 bytes in 0 blocks
==26506== Rerun with --leak-check=full to see details of leaked memory
==26506== 
==26506== For counts of detected and suppressed errors, rerun with: -v
==26506== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2)

But invoking the way I normally invoke it:

$ valgrind --leak-check=full --show-reachable=yes ./test
==26524== Memcheck, a memory error detector
==26524== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==26524== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==26524== Command: ./test
==26524== 
Leaked 0x51f2040
==26524== 
==26524== HEAP SUMMARY:
==26524==     in use at exit: 1 bytes in 1 blocks
==26524==   total heap usage: 1 allocs, 0 frees, 1 bytes allocated
==26524== 
==26524== 1 bytes in 1 blocks are still reachable in loss record 1 of 1
==26524==    at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==26524==    by 0x40059C: main (test.c:8)
==26524== 
==26524== LEAK SUMMARY:
==26524==    definitely lost: 0 bytes in 0 blocks
==26524==    indirectly lost: 0 bytes in 0 blocks
==26524==      possibly lost: 0 bytes in 0 blocks
==26524==    still reachable: 1 bytes in 1 blocks
==26524==         suppressed: 0 bytes in 0 blocks
==26524== 
==26524== For counts of detected and suppressed errors, rerun with: -v
==26524== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2)

Note the line numbers are again in brackets, e.g.

==26524==    by 0x40059C: main (test.c:8)
                                ^^^^^^^^ <- FILENAME AND LINE NUMBER