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

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

Using and understanding the Valgrind core
==15522== Uninitialised byte(s) found during client check request
==15522== at 0x400633: croak (varinfo1.c:28)
==15522== by 0x4006B2: main (varinfo1.c:55)
==15522== Location 0x60103b is 0 bytes inside global_i2[7],
==15522== a global variable declared at varinfo1.c:41
==15522==
==15522== Uninitialised byte(s) found during client check request
==15522== at 0x400633: croak (varinfo1.c:28)
==15522== by 0x4006BC: main (varinfo1.c:56)
==15522== Location 0x7fefffefc is 0 bytes inside local var "local"
==15522== declared at varinfo1.c:46, in frame #1 of thread 1
--vgdb-poll=<number> [default: 5000]
As part of its main loop, the Valgrind scheduler will poll to check if some activity (such as an external command or
some input from a gdb) has to be handled by gdbserver.
This activity poll will be done after having run the given
number of basic blocks (or slightly more than the given number of basic blocks). This poll is quite cheap so the default
value is set relatively low. You might further decrease this value if vgdb cannot use ptrace system call to interrupt
Valgrind if all threads are (most of the time) blocked in a system call.
--vgdb-shadow-registers=no|yes [default: no]
When activated, gdbserver will expose the Valgrind shadow registers to GDB. With this, the value of the Valgrind
shadow registers can be examined or changed using GDB. Exposing shadow registers only works with GDB version
7.1 or later.
--vgdb-prefix=<prefix> [default: /tmp/vgdb-pipe]
To communicate with gdb/vgdb, the Valgrind gdbserver creates 3 files (2 named FIFOs and a mmap shared memory
file). The prefix option controls the directory and prefix for the creation of these files.
--run-libc-freeres=<yes|no> [default: yes]
This option is only relevant when running Valgrind on Linux.
The GNU C library ( libc.so ), which is used by all programs, may allocate memory for its own uses. Usually it
doesn’t bother to free that memory when the program ends—there would be no point, since the Linux kernel reclaims
all process resources when a process exits anyway, so it would just slow things down.
The glibc authors realised that this behaviour causes leak checkers, such as Valgrind, to falsely report leaks in glibc,
when a leak check is done at exit.
In order to avoid this, they provided a routine called
__libc_freeres
specifically to make glibc release all memory it has allocated. Memcheck therefore tries to run
__libc_freeres
at exit.
Unfortunately, in some very old versions of glibc,
__libc_freeres
is sufficiently buggy to cause segmentation
faults. This was particularly noticeable on Red Hat 7.1. So this option is provided in order to inhibit the run
of
__libc_freeres
. If your program seems to run fine on Valgrind, but segfaults at exit, you may find that
--run-libc-freeres=no
fixes that, although at the cost of possibly falsely reporting space leaks in
libc.so
.
18