There are two possible causes of this.
First, by default, Valgrind only traces the top-level process.
So if your program spawns children, they won't be traced by Valgrind
by default. Also, if your program is started by a shell script,
Perl script, or something similar, Valgrind will trace the shell, or
the Perl interpreter, or equivalent.
To trace child processes, use the
--trace-children=yes option.
If you are tracing large trees of processes, it can be less
disruptive to have the output sent over the network. Give Valgrind
the option --log-socket=127.0.0.1:12345 (if you want
logging output sent to port 12345 on
localhost ). You can use the valgrind-listener
program to listen on that port:
valgrind-listener 12345
Obviously you have to start the listener process first. See
the manual for more details.
Second, if your program is statically linked, most Valgrind
tools will only work well if they are able to replace certain
functions, such as malloc , with their own
versions. By default, statically linked malloc
functions are not replaced. A key indicator of this is
if Memcheck says:
All heap blocks were freed -- no leaks are possible
when you know your program calls malloc . The
workaround is to use the option
--soname-synonyms=somalloc=NONE
or to avoid statically linking your program.
There will also be no replacement if you use an alternative
malloc library such as tcmalloc, jemalloc,
... In such a case, the
option --soname-synonyms=somalloc=zzzz (where
zzzz is the soname of the alternative malloc library) will allow
Valgrind to replace the functions.
|