Valgrind Software, Быстрый старт

Страница: 33 / 319

Using and understanding the Valgrind core
2.6.6. Debugging Options
There are also some options for debugging Valgrind itself. You shouldn’t need to use them in the normal run of
things. If you wish to see the list, use the --help-debug option.
If you wish to debug your program rather than debugging Valgrind itself, then you should use the options
--vgdb=yes
or
--vgdb=full
or
--db-attach=yes
.
2.6.7. Setting Default Options
Note that Valgrind also reads options from three places:
1. The file
~/.valgrindrc
2. The environment variable
$VALGRIND_OPTS
3. The file
./.valgrindrc
These are processed in the given order, before the command-line options. Options processed later override those
processed earlier; for example, options in ./.valgrindrc will take precedence over those in ~/.valgrindrc .
Please note that the
./.valgrindrc
file is ignored if it is marked as world writeable or not owned by the current
user. This is because the
./.valgrindrc
can contain options that are potentially harmful or can be used by a local
attacker to execute code under your user account.
Any tool-specific options put in
$VALGRIND_OPTS
or the
.valgrindrc
files should be prefixed with the tool
name and a colon. For example, if you want Memcheck to always do leak checking, you can put the following entry
in
~/.valgrindrc
:
--memcheck:leak-check=yes
This will be ignored if any tool other than Memcheck is run. Without the
memcheck:
part, this will cause problems
if you select other tools that don’t understand
--leak-check=yes
.
2.7. Support for Threads
Threaded programs are fully supported.
The main thing to point out with respect to threaded programs is that your program will use the native threading
library, but Valgrind serialises execution so that only one (kernel) thread is running at a time. This approach avoids
the horrible implementation problems of implementing a truly multithreaded version of Valgrind, but it does mean that
threaded apps never use more than one CPU simultaneously, even if you have a multiprocessor or multicore machine.
Valgrind doesn’t schedule the threads itself. It merely ensures that only one thread runs at once, using a simple
locking scheme. The actual thread scheduling remains under control of the OS kernel. What this does mean, though,
is that your program will see very different scheduling when run on Valgrind than it does when running normally. This
is both because Valgrind is serialising the threads, and because the code runs so much slower than normal.
This difference in scheduling may cause your program to behave differently, if you have some kind of concurrency,
critical race, locking, or similar, bugs. In that case you might consider using the tools Helgrind and/or DRD to track
them down.
21