14

How do you get Valgrind to show exactly where an error occured? I compiled my program (on a Windows machine over a Linux terminal via PuTTy) adding the -g debug option.

When I run Valgrind, I get the Leak and Heap summary, and I definitely have lost memory, but I never get information about where it happens (file name, line). Shouldn't Valgrind be telling me on what line after I allocate memory, it fails to deallocate later?

==15746== ==15746== HEAP SUMMARY: ==15746== in use at exit: 54 bytes in 6 blocks ==15746== total heap usage: 295 allocs, 289 frees, 11,029 bytes allocated ==15746== ==15746== LEAK SUMMARY: ==15746== definitely lost: 12 bytes in 3 blocks ==15746== indirectly lost: 42 bytes in 3 blocks ==15746== possibly lost: 0 bytes in 0 blocks ==15746== still reachable: 0 bytes in 0 blocks ==15746== suppressed: 0 bytes in 0 blocks ==15746== Rerun with --leak-check=full to see details of leaked memory ==15746== ==15746== For counts of detected and suppressed errors, rerun with: -v ==15746== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 15 from 8) 
4
  • Yes, it should. Can you paste valgrind output here? Are you running valgrind in verbose mode? Commented Oct 17, 2011 at 18:25
  • Added the output. It says to rerun with --leak-check=full, but I did run it with that flag. Don't know why it's not working. Even with -v mode, I always get the same information. Commented Oct 17, 2011 at 19:18
  • Are you saying that leak-check option is not supported in valgrind? Commented Oct 18, 2011 at 2:29
  • Refer to this page: stackoverflow.com/questions/9321385/… It gives information of flags to be set Commented Apr 17, 2013 at 4:48

5 Answers 5

17

I've repeatedly gotten hosed on this, and couldn't figure out why '--leak-check=full' wasn't working for me, so I thought I'd bump up tune2fs comment.

The most likely problem is that you've (Not ShrimpCrackers, but whoever is reading this post right now) placed --leak-check=full at the end of your command line. Valgrind would like you to post the flag before you enter the actual command line to run your program.

i.e.:

valgrind --leak-check=full ./myprogram 

NOT:

valgrind ./myprogram --leak-check=full 
Sign up to request clarification or add additional context in comments.

Comments

12

It's not an option related to valgrind. Instead, the code have to be compiled with -g options, in order to preserve the debug symbol.

cc -g main.c valgrind --trace-children=yes --track-fds=yes --track-origins=yes --leak-check=full --show-leak-kinds=all ./a.out 

1 Comment

I dont know why this is not the accepted answer
9

Try valgrind --leak-check=full

This normally prints more useful information. Also add the -O0 flag when compiling so your code doesn't get optimized.

5 Comments

Tried it, nothing new. Maybe Valgrind shows write/read errors...but can't show where memory leaks occur? Only that there is a memory leak?
with the leak-check flag you will not get an exact line number. But you will find the name of the function where the memory leak occured. For example: by 0x10000B311: LibpipeCreatorTestSuite::testMemory() (in ./test_libpipecreator)
Any other suggestions? The flag parameters do not work for me.
can you give us the output of: valgrind --leak-check=full ./yourprogram
tune2fs, thanks! I was doing valgrind ./myprogram --leak-check=full which is probably why it didn't work.
6

Let me be more specific for other readers (i had the same problem but my arguments were in the right order): I found out that valgrind needs the path to the executable, if you dont give this then it will run bu it won't give you the line numbers. In my case the executable was in a different directory, which was in my PATH, but to get the line information you have to run

valgrind --leak-check=full path_to_myprogram/myprogram 

Comments

1

In order for valgrind to show the lines where the errors occurred in the file, I had to add -g to the END of my compile command.

For Example:

gcc -o main main.c -g 

Then just run valgrind:

valgrind --leak-check=full --show-leak-kinds=all --track-origins=yes ./main 

1 Comment

it does not have to go at the end, this works fine: gcc -g -o main main.c

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.