Memcheck: a memory error detector
So
s1
occupies 8 bytes, yet only 5 of them will be initialised. For the assignment
s2 = s1
, GCC generates code
to copy all 8 bytes wholesale into
s2
without regard for their meaning. If Memcheck simply checked values as they
came out of memory, it would yelp every time a structure assignment like this happened. So the more complicated
behaviour described above is necessary. This allows GCC to copy
s1
into
s2
any way it likes, and a warning will
only be emitted if the uninitialised values are later used.
4.5.2. Valid-address (A) bits
Notice that the previous subsection describes how the validity of values is established and maintained without having
to say whether the program does or does not have the right to access any particular memory location. We now consider
the latter question.
As described above, every bit in memory or in the CPU has an associated valid-value (V) bit. In addition, all bytes
in memory, but not in the CPU, have an associated valid-address (A) bit. This indicates whether or not the program
can legitimately read or write that location. It does not give any indication of the validity of the data at that location
-- that’s the job of the V bits -- only whether or not the location may be accessed.
Every time your program reads or writes memory, Memcheck checks the A bits associated with the address. If any of
them indicate an invalid address, an error is emitted. Note that the reads and writes themselves do not change the A
bits, only consult them.
So how do the A bits get set/cleared? Like this:
• When the program starts, all the global data areas are marked as accessible.
• When the program does
malloc
/
new
, the A bits for exactly the area allocated, and not a byte more, are marked as
accessible. Upon freeing the area the A bits are changed to indicate inaccessibility.
• When the stack pointer register (
SP
) moves up or down, A bits are set.
The rule is that the area from
SP
up to
the base of the stack is marked as accessible, and below
SP
is inaccessible. (If that sounds illogical, bear in mind
that the stack grows down, not up, on almost all Unix systems, including GNU/Linux.) Tracking
SP
like this has
the useful side-effect that the section of stack used by a function for local variables etc is automatically marked
accessible on function entry and inaccessible on exit.
• When doing system calls, A bits are changed appropriately. For example,
mmap
magically makes files appear in the
process’ address space, so the A bits must be updated if
mmap
succeeds.
• Optionally, your program can tell Memcheck about such changes explicitly, using the client request mechanism
described above.
4.5.3. Putting it all together
Memcheck’s checking machinery can be summarised as follows:
• Each byte in memory has 8 associated V (valid-value) bits, saying whether or not the byte has a defined value, and
a single A (valid-address) bit, saying whether or not the program currently has the right to read/write that address.
As mentioned above, heavy use of compression means the overhead is typically around 25%.
• When memory is read or written, the relevant A bits are consulted. If they indicate an invalid address, Memcheck
emits an Invalid read or Invalid write error.
62
Содержание BBV
Страница 176: ...Valgrind FAQ Release 3 8 0 10 August 2012 Copyright 2000 2012 Valgrind Developers Email valgrind valgrind org ...
Страница 177: ...Valgrind FAQ Table of Contents Valgrind Frequently Asked Questions 1 ii ...
Страница 302: ...README mips based on newer GCC versions if possible 95 ...
Страница 303: ...GNU Licenses ...
Страница 304: ...GNU Licenses Table of Contents 1 The GNU General Public License 1 2 The GNU Free Documentation License 8 ii ...