Valgrind Frequently Asked Questions
If they’re not long enough, use
--num-callers
to make them longer.
If they’re not detailed enough, make sure you are compiling with
-g
to add debug information. And don’t strip
symbol tables (programs should be unstripped unless you run ’strip’ on them; some libraries ship stripped).
Also, for leak reports involving shared objects, if the shared object is unloaded before the program terminates,
Valgrind will discard the debug information and the error message will be full of
???
entries. The workaround
here is to avoid calling
dlclose
on these shared objects.
Also,
-fomit-frame-pointer
and
-fstack-check
can make stack traces worse.
Some example sub-traces:
• With debug information and unstripped (best):
Invalid write of size 1
at 0x80483BF: really (malloc1.c:20)
by 0x8048370: main (malloc1.c:9)
• With no debug information, unstripped:
Invalid write of size 1
at 0x80483BF: really (in /auto/homes/njn25/grind/head5/a.out)
by 0x8048370: main (in /auto/homes/njn25/grind/head5/a.out)
• With no debug information, stripped:
Invalid write of size 1
at 0x80483BF: (within /auto/homes/njn25/grind/head5/a.out)
by 0x8048370: (within /auto/homes/njn25/grind/head5/a.out)
by 0x42015703: __libc_start_main (in /lib/tls/libc-2.3.2.so)
by 0x80482CC: (within /auto/homes/njn25/grind/head5/a.out)
• With debug information and -fomit-frame-pointer:
Invalid write of size 1
at 0x80483C4: really (malloc1.c:20)
by 0x42015703: __libc_start_main (in /lib/tls/libc-2.3.2.so)
by 0x80482CC: ??? (start.S:81)
5