How to get the full call stack from Valgrind?

Question

I run Valgrind with the following parameters:

--leak-check=full --show-reachable=yes --leak-resolution=high --num-callers=100 --trace-children=yes

In memory leaks log, I see some error messages with full stack trace up to main, but some messages look like following:

==3956== 1,999,140 (68,796 direct, 1,930,344 indirect) bytes in 5,733 blocks are definitely lost in loss record 8,842 of 8,845
==3956==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==3956== 

How can I get the full stack trace for these errors?

Austerity

The last released version of Valgrind only supports --num-callers till 50. So, it is not clear which version you are using. The above stack trace looks incomplete. This might be linked to the way your application is compiled (e.g. option -fomit-frame-pointer might make the stack trace more difficult to produce) – Islington

Bump. (does stackoverflow "bump" posts?) Same problem. Compiling an application with -g. It shows possible memory leaks with a stack trace staring from malloc(), the function that called malloc(), and then main(), skipping everything in between, including functions within the same file as main(). ?? I see examples online that don't have this 3 stack frame limit..?? Any ideas? – Cristen

I'm using valgrind 3.8.1 on Ubuntu 13.10 and see stack traces that doesn't contain all intermediate calls. No optimization while compiling with gcc (or maybe I need -Og or something...) – Adur

Have you ensured you have debug symbols installed for all libraries your application links to? – Ronel

Answer 1

Getting the full stack trace will require debug symbols for all the libraries/executables that may be involved in a leak (and within the limits set by --num-callers).

If you're building any of them yourself, you need to specify the -g flag in gcc (or the relevant flag in any other compiler).

Note that valgrind is not foolproof, and may occasionally miss leaks or be unable to provide full stack traces (especially if you're using threads, or complicated class implementations).

For libraries without debug information, the stack trace will stop at that library.

For a free tool, valgrind is very good at what it does, but there is a reason places like IBM can sell memory profiles for big money.

Typescript

Thanks, in my case I just had to adjust the --num-callers option. The default appears to be 12, which is pretty low for the STL and the like. – Defazio

For future viewers, to view the full call stack, run valgrind with --num-callers=<x>, with x being between 1 and 500. Setting it to 500 will lead to the full stack being printed. – Lugar

Basically, the accepted answer should be these comments ^ – Trutko

I believe the other values are part of the answer - it just appears that most people get tripped up by --num-callers – Typescript

Answer 2

I had a similar issue where Valgrind was only showing library files in the stack trace. I managed to solve that by specifying --num-callers=500, that made it show the full stack trace up to main.cpp. (The default value for --num-callers is 12 which is too low for some libraries).

Bohrer