> valgrind --tool=callgrind --ct-verbose=1 ...
When I run callgrind and callgrind_annotate, then I don't understand
the output. For instance, the connection between "73" and the number
of actual dynamic calls to exit() is mysterious to me:
=====
$ valgrind --tool=callgrind /bin/date
==3790== Using Valgrind-3.6.0 and LibVEX; rerun with -h for copyright info
$ callgrind_annotate callgrind.out*
Ir file:function
73 /usr/src/debug/glibc-2.13/stdlib/exit.c:exit [/lib64/libc-2.13.so]
-----/usr/src/debug/glibc-2.13/stdlib/exit.c
void
exit (int status)
{
__run_exit_handlers (status, &__exit_funcs, true);
}
-----
$ gdb /bin/date
(gdb) b exit
(gdb) run
Thu Jul 7 08:52:35 PDT 2011
Breakpoint 1, exit (status=0x0) at exit.c:99
(gdb) list ## we are at the right place
97 void
98 exit (int status)
99 {
100 __run_exit_handlers (status, &__exit_funcs, true);
101 }
102 libc_hidden_def (exit)
(gdb) continue
$ ## was called only once, not 73 times.
=====
For another instance, using the exact suggestion:
$ valgrind --tool=callgrind --ct-verbose=1 /bin/date
gives output such as:
-----
. . . > check_match.10789(0x3d, 0x5b, ...) [ld-2.13.so / 0x3d25a08a20]
. . . .> strcmp(0x3d, 0x5b, ...) [ld-2.13.so / 0x3d25a16ac0]
. . . . > strcmp(0x3d, 0x5b, ...) [ld-2.13.so / 0x3d25a16ac0]
-----
where the indicated parameters are nonsense, and a function whose body
is a loop displays as a recursion. It is hard for me to trust such output.
--
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
