At the end of the program run, "leak check full" "show leak kinds all" shows a number of leak incidents in the form of sections like this, just as an example:
[...]
==12522==
==12522== x bytes in 1 blocks are still reachable in loss record y of z
==12522== at 0x4C2BBAF: malloc (vg_replace_malloc.c:299)
==12522== by 0x42350D: whatever_1 (whatever_1.c:3401)
==12522== by 0x4225B9: whatever_2 (whatever_2.c:2948)
==12522== by 0x41D93E: whatever_3 (whatever_3.c:1185)
==12522== by 0x423A07: whatever_4 (whatever_4.c:1370)
==12522== by 0x4294A4: whatever_5 (whatever_5.y:1413)
==12522== by 0x403998: whatever_6 (whatever_6.c:205)
==12522== by 0x4038AC: whatever_7 (whatever_7.c:180)
==12522== by 0x4036AF: whatever_8 (whatever_8.c:143)
==12522== by 0x413C7F: whatever_test_0 (whatever_9.c:53)
==12522== by 0x413F92: whatever_tests (whatever_10.c:177)
==12522== by 0x45AD69: run_tests (whatever_11.c:153)
==12522==
[...]
The topmost scope is main, and in multiple blocks, like this one, there is enough depth that the call stack doesn't show up to main. In other incidents, there's enough context to show every level.
I've seen that, in this host, only 12 levels are shown here (vg_replace_malloc.c then my 11 user levels).
Can this be configured to show more than 12 levels?
I've read Valgrind arguments, Memcheck arguments, have increased verbosity, with no success.
Use the option --num-callers (that has default value 12):
--num-callers=<number> show <number> callers in stack traces [12]