## 3. Memcheck: a heavyweight memory checker

To use this tool, you may specify `--tool=memcheck` on the Valgrind command line. You don't have to, though, since Memcheck is the default tool.

## 3.1. Kinds of bugs that Memcheck can find

Memcheck is Valgrind's heavyweight memory checking tool. All reads and writes of memory are checked, and calls to malloc/new/free/delete are intercepted. As a result, Memcheck can detect the following problems:

- Use of uninitialised memory

- Reading/writing memory after it has been free'd

- Reading/writing off the end of malloc'd blocks

- Reading/writing inappropriate areas on the stack

- Memory leaks -- where pointers to malloc'd blocks are lost forever

- Mismatched use of malloc/new/new [] vs free/delete/delete []

- Overlapping `src` and `dst` pointers in `memcpy()` and related functions

## 3.2. Command-line flags specific to Memcheck

- `--leak-check=no`

  `--leak-check=summary` [default]

  `--leak-check=full`

  When enabled, search for memory leaks when the client program finishes. A memory leak means a malloc'd block, which has not yet been free'd, but to which no pointer can be found. Such a block can never be free'd by the program, since no pointer to it exists. If set to `summary`, it says how many leaks occurred. If set to `all`, it gives details of each individual leak.

- `--show-reachable=no` [default]

  `--show-reachable=yes`

  When disabled, the memory leak detector only shows blocks for which it cannot find a pointer to at all, or it can only find a pointer to the middle of. These blocks are prime candidates for memory leaks. When enabled, the leak detector also reports on blocks which it could find a pointer to. Your program could, at least in principle, have freed such blocks before exit. Contrast this to blocks for which no pointer, or only an interior pointer could be found: they are more likely to indicate memory leaks, because you do not actually have a pointer to the start of the block which you can hand to `free`, even if you wanted to.

- `--undef-value-errors=yes` [default]

  `--undef-value-errors=no`

  When enabled (default), Memcheck tracks and detects (mis)use of undefined values. A program may copy around junk (undefined) data as much as it likes: Memcheck keeps track of this data, but only complains when the program actually attempts to use it. When disabled, this class of errors is ignored (previous users of Addrcheck may like this option).

- `--leak-resolution=low` [default]

  `--leak-resolution=med`

  `--leak-resolution=high`

  When doing leak checking, determines how willing Memcheck is to consider different backtraces to be the same. When set to `low`, the default, only the first two entries need match. When `med`, four entries have to match. When `high`, all entries need to match.

  For hardcore leak debugging, you probably want to use `--leak-resolution=high` together with `--num-callers=40` or some such large number. Note however that this can give an overwhelming amount of information, which is why the defaults are 4 callers and low-resolution matching.

  Note that the `--leak-resolution=` setting does not affect Memcheck's ability to find leaks. It only changes how the results are presented.

- `--freelist-vol=<number>` [default: 5000000]

  When the client program releases memory using free (in `C`) or delete (`C++`), that memory is not immediately made available for re-allocation. Instead it is marked inaccessible and placed in a queue of freed blocks. The purpose is to defer as long as possible the point at which freed-up memory comes back into circulation. This increases the chance that Memcheck will be able to detect invalid accesses to blocks for some significant period of time after they have been freed.

  This flag specifies the maximum total size, in bytes, of the blocks in the queue. The default value is five million bytes. Increasing this increases the total amount of memory used by Memcheck but may detect invalid uses of freed blocks which would otherwise go undetected.

- `--workaround-gcc296-bugs=no` [default]

  `--workaround-gcc296-bugs=yes`

  When enabled, assume that reads and writes some small distance below the stack pointer are due to bugs in gcc 2.96, and does not report them. The "small distance" is 256 bytes by default. Note that gcc 2.96 is the default compiler on some older Linux distributions (RedHat 7.X) and so you may need to use this flag. Do not use it if you do not have to, as it can cause real errors to be overlooked. A better alternative is to use a more recent gcc/g++ in which this bug is fixed.

- `--partial-loads-ok=yes`

  `--partial-loads-ok=no`[default]

  Controls how Memcheck handles word-sized, word-aligned loads from addresses for which some bytes are addressible and others are not. When `yes`, such loads do not elicit an address error. Instead, the loaded V bytes corresponding to the illegal addresses indicate Undefined, and those corresponding to legal addresses are loaded from shadow memory, as usual.

  When `no`(the default), loads from partially invalid addresses are treated the same as loads from completely invalid addresses: an illegal-address error is issued, and the resulting V bytes indicate valid data.

  Note that code that behaves in this way is in violation of the the ISO C/C++ standards, and should be considered broken. If at all possible, such code should be fixed. This flag should be used only as a last resort.

## 3.3. Explanation of error messages from Memcheck

Despite considerable sophistication under the hood, Memcheck can only really detect two kinds of errors: use of illegal addresses, and use of undefined values. Nevertheless, this is enough to help you discover all sorts of memory-management nasties in your code. This section presents a quick summary of what error messages mean. The precise behaviour of the error-checking machinery is described in Details of Memcheck's checking machinery.

### 3.3.1. Illegal read / Illegal write errors

For example:

    Invalid read of size 4
       at 0x40F6BBCC: (within /usr/lib/libpng.so.2.1.0.9)
       by 0x40F6B804: (within /usr/lib/libpng.so.2.1.0.9)
       by 0x40B07FF4: read_png_image__FP8QImageIO (kernel/qpngio.cpp:326)
       by 0x40AC751B: QImageIO::read() (kernel/qimage.cpp:3621)
     Address 0xBFFFF0E0 is not stack'd, malloc'd or free'd

This happens when your program reads or writes memory at a place which Memcheck reckons it shouldn't. In this example, the program did a 4-byte read at address 0xBFFFF0E0, somewhere within the system-supplied library libpng.so.2.1.0.9, which was called from somewhere else in the same library, called from line 326 of `qpngio.cpp`, and so on.

Memcheck tries to establish what the illegal address might relate to, since that's often useful. So, if it points into a block of memory which has already been freed, you'll be informed of this, and also where the block was free'd at. Likewise, if it should turn out to be just off the end of a malloc'd block, a common result of off-by-one-errors in array subscripting, you'll be informed of this fact, and also where the block was malloc'd.

In this example, Memcheck can't identify the address. Actually the address is on the stack, but, for some reason, this is not a valid stack address -- it is below the stack pointer and that isn't allowed. In this particular case it's probably caused by gcc generating invalid code, a known bug in some ancient versions of gcc.

Note that Memcheck only tells you that your program is about to access memory at an illegal address. It can't stop the access from happening. So, if your program makes an access which normally would result in a segmentation fault, you program will still suffer the same fate -- but you will get a message from Memcheck immediately prior to this. In this particular example, reading junk on the stack is non-fatal, and the program stays alive.

### 3.3.2. Use of uninitialised values

For example:

    Conditional jump or move depends on uninitialised value(s)
       at 0x402DFA94: _IO_vfprintf (_itoa.h:49)
       by 0x402E8476: _IO_printf (printf.c:36)
       by 0x8048472: main (tests/manuel1.c:8)

An uninitialised-value use error is reported when your program uses a value which hasn't been initialised -- in other words, is undefined. Here, the undefined value is used somewhere inside the printf() machinery of the C library. This error was reported when running the following small program:

    int main()
    {
      int x;
      printf ("x = %d\n", x);
    }

It is important to understand that your program can copy around junk (uninitialised) data as much as it likes. Memcheck observes this and keeps track of the data, but does not complain. A complaint is issued only when your program attempts to make use of uninitialised data. In this example, x is uninitialised. Memcheck observes the value being passed to `_IO_printf` and thence to `_IO_vfprintf`, but makes no comment. However, _IO_vfprintf has to examine the value of x so it can turn it into the corresponding ASCII string, and it is at this point that Memcheck complains.

Sources of uninitialised data tend to be:

- Local variables in procedures which have not been initialised, as in the example above.

- The contents of malloc'd blocks, before you write something there. In C++, the new operator is a wrapper round malloc, so if you create an object with new, its fields will be uninitialised until you (or the constructor) fill them in, which is only Right and Proper.

### 3.3.3. Illegal frees

For example:

    Invalid free()
       at 0x4004FFDF: free (vg_clientmalloc.c:577)
       by 0x80484C7: main (tests/doublefree.c:10)
     Address 0x3807F7B4 is 0 bytes inside a block of size 177 free'd
       at 0x4004FFDF: free (vg_clientmalloc.c:577)
       by 0x80484C7: main (tests/doublefree.c:10)

Memcheck keeps track of the blocks allocated by your program with malloc/new, so it can know exactly whether or not the argument to free/delete is legitimate or not. Here, this test program has freed the same block twice. As with the illegal read/write errors, Memcheck attempts to make sense of the address free'd. If, as here, the address is one which has previously been freed, you wil be told that -- making duplicate frees of the same block easy to spot.

### 3.3.4. When a block is freed with an inappropriate deallocation function

In the following example, a block allocated with `new[]` has wrongly been deallocated with `free`:

    Mismatched free() / delete / delete []
       at 0x40043249: free (vg_clientfuncs.c:171)
       by 0x4102BB4E: QGArray::~QGArray(void) (tools/qgarray.cpp:149)
       by 0x4C261C41: PptDoc::~PptDoc(void) (include/qmemarray.h:60)
       by 0x4C261F0E: PptXml::~PptXml(void) (pptxml.cc:44)
     Address 0x4BB292A8 is 0 bytes inside a block of size 64 alloc'd
       at 0x4004318C: __builtin_vec_new (vg_clientfuncs.c:152)
       by 0x4C21BC15: KLaola::readSBStream(int) const (klaola.cc:314)
       by 0x4C21C155: KLaola::stream(KLaola::OLENode const *) (klaola.cc:416)
       by 0x4C21788F: OLEFilter::convert(QCString const &) (olefilter.cc:272)

In `C++` it's important to deallocate memory in a way compatible with how it was allocated. The deal is:

- If allocated with `malloc`, `calloc`, `realloc`, `valloc` or `memalign`, you must deallocate with `free`.

- If allocated with `new[]`, you must deallocate with `delete[]`.

- If allocated with `new`, you must deallocate with `delete`.

The worst thing is that on Linux apparently it doesn't matter if you do muddle these up, and it all seems to work ok, but the same program may then crash on a different platform, Solaris for example. So it's best to fix it properly. According to the KDE folks "it's amazing how many C++ programmers don't know this".

Pascal Massimino adds the following clarification: `delete[]` must be used for objects allocated by `new[]` because the compiler stores the size of the array and the pointer-to-member to the destructor of the array's content just before the pointer actually returned. This implies a variable-sized overhead in what's returned by `new` or `new[]`.

### 3.3.5. Passing system call parameters with inadequate read/write permissions

Memcheck checks all parameters to system calls:

- It checks all the direct parameters themselves.

- Also, if a system call needs to read from a buffer provided by your program, Memcheck checks that the entire buffer is addressible and has valid data, ie, it is readable.

- Also, if the system call needs to write to a user-supplied buffer, Memcheck checks that the buffer is addressible.

After the system call, Memcheck updates its tracked information to precisely reflect any changes in memory permissions caused by the system call.

Here's an example of two system calls with invalid parameters:

      #include <stdlib.h>
      #include <unistd.h>
      int main( void )
      {
        char* arr  = malloc(10);
        int*  arr2 = malloc(sizeof(int));
        write( 1 /* stdout */, arr, 10 );
        exit(arr2[0]);
      }

You get these complaints ...

      Syscall param write(buf) points to uninitialised byte(s)
         at 0x25A48723: __write_nocancel (in /lib/tls/libc-2.3.3.so)
         by 0x259AFAD3: __libc_start_main (in /lib/tls/libc-2.3.3.so)
         by 0x8048348: (within /auto/homes/njn25/grind/head4/a.out)
       Address 0x25AB8028 is 0 bytes inside a block of size 10 alloc'd
         at 0x259852B0: malloc (vg_replace_malloc.c:130)
         by 0x80483F1: main (a.c:5)

      Syscall param exit(error_code) contains uninitialised byte(s)
         at 0x25A21B44: __GI__exit (in /lib/tls/libc-2.3.3.so)
         by 0x8048426: main (a.c:8)

... because the program has (a) tried to write uninitialised junk from the malloc'd block to the standard output, and (b) passed an uninitialised value to `exit`. Note that the first error refers to the memory pointed to by `buf` (not `buf` itself), but the second error refers to the argument `error_code` itself.

### 3.3.6. Overlapping source and destination blocks

The following C library functions copy some data from one memory block to another (or something similar): `memcpy()`, `strcpy()`, `strncpy()`, `strcat()`, `strncat()`. The blocks pointed to by their `src` and `dst` pointers aren't allowed to overlap. Memcheck checks for this.

For example:

    ==27492== Source and destination overlap in memcpy(0xbffff294, 0xbffff280, 21)
    ==27492==    at 0x40026CDC: memcpy (mc_replace_strmem.c:71)
    ==27492==    by 0x804865A: main (overlap.c:40)
    ==27492==

You don't want the two blocks to overlap because one of them could get partially trashed by the copying.

You might think that Memcheck is being overly pedantic reporting this in the case where `dst` is less than `src`. For example, the obvious way to implement `memcpy()` is by copying from the first byte to the last. However, the optimisation guides of some architectures recommend copying from the last byte down to the first. Also, some implementations of `memcpy()` zero `dst` before copying, because zeroing the destination's cache line(s) can improve performance.

The moral of the story is: if you want to write truly portable code, don't make any assumptions about the language implementation.

### 3.3.7. Memory leak detection

Memcheck keeps track of all memory blocks issued in response to calls to malloc/calloc/realloc/new. So when the program exits, it knows which blocks have not been freed.

If `--leak-check` is set appropriately, for each remaining block, Memcheck scans the entire address space of the process, looking for pointers to the block. Each block fits into one of the three following categories.

- Still reachable: A pointer to the start of the block is found. This usually indicates programming sloppiness. Since the block is still pointed at, the programmer could, at least in principle, free it before program exit. Because these are very common and arguably not a problem, Memcheck won't report such blocks unless `--show-reachable=yes` is specified.

- Possibly lost, or "dubious": A pointer to the interior of the block is found. The pointer might originally have pointed to the start and have been moved along, or it might be entirely unrelated. Memcheck deems such a block as "dubious", because it's unclear whether or not a pointer to it still exists.

- Definitely lost, or "leaked": The worst outcome is that no pointer to the block can be found. The block is classified as "leaked", because the programmer could not possibly have freed it at program exit, since no pointer to it exists. This is likely a symptom of having lost the pointer at some earlier point in the program.

For each block mentioned, Memcheck will also tell you where the block was allocated. It cannot tell you how or why the pointer to a leaked block has been lost; you have to work that out for yourself. In general, you should attempt to ensure your programs do not have any leaked or dubious blocks at exit.

For example:

    8 bytes in 1 blocks are definitely lost in loss record 1 of 14
       at 0x........: malloc (vg_replace_malloc.c:...)
       by 0x........: mk (leak-tree.c:11)
       by 0x........: main (leak-tree.c:39)

    88 (8 direct, 80 indirect) bytes in 1 blocks are definitely lost
                               in loss record 13 of 14
       at 0x........: malloc (vg_replace_malloc.c:...)
       by 0x........: mk (leak-tree.c:11)
       by 0x........: main (leak-tree.c:25)

The first message describes a simple case of a single 8 byte block that has been definitely lost. The second case mentions both "direct" and "indirect" leaks. The distinction is that a direct leak is a block which has no pointers to it. An indirect leak is a block which is only pointed to by other leaked blocks. Both kinds of leak are bad.

The precise area of memory in which Memcheck searches for pointers is: all naturally-aligned machine-word-sized words for which all A bits indicate addressibility and all V bits indicated that the stored value is actually valid.

## 3.4. Writing suppression files

The basic suppression format is described in Suppressing errors.

The suppression (2nd) line should have the form:

    Memcheck:suppression_type

Or, since some of the suppressions are shared with Addrcheck:

    Memcheck,Addrcheck:suppression_type

The Memcheck suppression types are as follows:

- `Value1`, `Value2`, `Value4`, `Value8`, `Value16`, meaning an uninitialised-value error when using a value of 1, 2, 4, 8 or 16 bytes.

- Or: `Cond` (or its old name, `Value0`), meaning use of an uninitialised CPU condition code.

- Or: `Addr1`, `Addr2`, `Addr4`, `Addr8`, `Addr16`, meaning an invalid address during a memory access of 1, 2, 4, 8 or 16 bytes respectively.

- Or: `Param`, meaning an invalid system call parameter error.

- Or: `Free`, meaning an invalid or mismatching free.

- Or: `Overlap`, meaning a `src` / `dst` overlap in `memcpy() or a similar function`.

- Or: `Leak`, meaning a memory leak.

The extra information line: for Param errors, is the name of the offending system call parameter. No other error kinds have this extra line.

The first line of the calling context: for Value and Addr errors, it is either the name of the function in which the error occurred, or, failing that, the full path of the .so file or executable containing the error location. For Free errors, is the name of the function doing the freeing (eg, `free`, `__builtin_vec_delete`, etc). For Overlap errors, is the name of the function with the overlapping arguments (eg. `memcpy()`, `strcpy()`, etc).

Lastly, there's the rest of the calling context.

## 3.5. Details of Memcheck's checking machinery

Read this section if you want to know, in detail, exactly what and how Memcheck is checking.

### 3.5.1. Valid-value (V) bits

It is simplest to think of Memcheck implementing a synthetic CPU which is identical to a real CPU, except for one crucial detail. Every bit (literally) of data processed, stored and handled by the real CPU has, in the synthetic CPU, an associated "valid-value" bit, which says whether or not the accompanying bit has a legitimate value. In the discussions which follow, this bit is referred to as the V (valid-value) bit.

Each byte in the system therefore has a 8 V bits which follow it wherever it goes. For example, when the CPU loads a word-size item (4 bytes) from memory, it also loads the corresponding 32 V bits from a bitmap which stores the V bits for the process' entire address space. If the CPU should later write the whole or some part of that value to memory at a different address, the relevant V bits will be stored back in the V-bit bitmap.

In short, each bit in the system has an associated V bit, which follows it around everywhere, even inside the CPU. Yes, all the CPU's registers (integer, floating point, vector and condition registers) have their own V bit vectors.

Copying values around does not cause Memcheck to check for, or report on, errors. However, when a value is used in a way which might conceivably affect the outcome of your program's computation, the associated V bits are immediately checked. If any of these indicate that the value is undefined, an error is reported.

Here's an (admittedly nonsensical) example:

    int i, j;
    int a[10], b[10];
    for ( i = 0; i < 10; i++ ) {
      j = a[i];
      b[i] = j;
    }

Memcheck emits no complaints about this, since it merely copies uninitialised values from `a[]` into `b[]`, and doesn't use them in any way. However, if the loop is changed to:

    for ( i = 0; i < 10; i++ ) {
      j += a[i];
    }
    if ( j == 77 )
      printf("hello there\n");

then Valgrind will complain, at the `if`, that the condition depends on uninitialised values. Note that it doesn't complain at the `j += a[i];`, since at that point the undefinedness is not "observable". It's only when a decision has to be made as to whether or not to do the `printf` -- an observable action of your program -- that Memcheck complains.

Most low level operations, such as adds, cause Memcheck to use the V bits for the operands to calculate the V bits for the result. Even if the result is partially or wholly undefined, it does not complain.

Checks on definedness only occur in three places: when a value is used to generate a memory address, when control flow decision needs to be made, and when a system call is detected, Valgrind checks definedness of parameters as required.

If a check should detect undefinedness, an error message is issued. The resulting value is subsequently regarded as well-defined. To do otherwise would give long chains of error messages. In effect, we say that undefined values are non-infectious.

This sounds overcomplicated. Why not just check all reads from memory, and complain if an undefined value is loaded into a CPU register? Well, that doesn't work well, because perfectly legitimate C programs routinely copy uninitialised values around in memory, and we don't want endless complaints about that. Here's the canonical example. Consider a struct like this:

    struct S { int x; char c; };
    struct S s1, s2;
    s1.x = 42;
    s1.c = 'z';
    s2 = s1;

The question to ask is: how large is `struct S`, in bytes? An `int` is 4 bytes and a `char` one byte, so perhaps a `struct S` occupies 5 bytes? Wrong. All (non-toy) compilers we know of will round the size of `struct S` up to a whole number of words, in this case 8 bytes. Not doing this forces compilers to generate truly appalling code for subscripting arrays of `struct S`'s.

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 semantics 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.

### 3.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 issue.

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 or 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 Valgrind about such changes explicitly, using the client request mechanism described above.

### 3.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.

- When memory is read or written, the relevant A bits are consulted. If they indicate an invalid address, Valgrind emits an Invalid read or Invalid write error.

- When memory is read into the CPU's registers, the relevant V bits are fetched from memory and stored in the simulated CPU. They are not consulted.

- When a register is written out to memory, the V bits for that register are written back to memory too.

- When values in CPU registers are used to generate a memory address, or to determine the outcome of a conditional branch, the V bits for those values are checked, and an error emitted if any of them are undefined.

- When values in CPU registers are used for any other purpose, Valgrind computes the V bits for the result, but does not check them.

- One the V bits for a value in the CPU have been checked, they are then set to indicate validity. This avoids long chains of errors.

- When values are loaded from memory, valgrind checks the A bits for that location and issues an illegal-address warning if needed. In that case, the V bits loaded are forced to indicate Valid, despite the location being invalid.

  This apparently strange choice reduces the amount of confusing information presented to the user. It avoids the unpleasant phenomenon in which memory is read from a place which is both unaddressible and contains invalid values, and, as a result, you get not only an invalid-address (read/write) error, but also a potentially large set of uninitialised-value errors, one for every time the value is used.

  There is a hazy boundary case to do with multi-byte loads from addresses which are partially valid and partially invalid. See details of the flag `--partial-loads-ok` for details.

Memcheck intercepts calls to malloc, calloc, realloc, valloc, memalign, free, new, new[], delete and delete[]. The behaviour you get is:

- malloc/new/new[]: the returned memory is marked as addressible but not having valid values. This means you have to write on it before you can read it.

- calloc: returned memory is marked both addressible and valid, since calloc() clears the area to zero.

- realloc: if the new size is larger than the old, the new section is addressible but invalid, as with malloc.

- If the new size is smaller, the dropped-off section is marked as unaddressible. You may only pass to realloc a pointer previously issued to you by malloc/calloc/realloc.

- free/delete/delete[]: you may only pass to these functions a pointer previously issued to you by the corresponding allocation function. Otherwise, Valgrind complains. If the pointer is indeed valid, Valgrind marks the entire area it points at as unaddressible, and places the block in the freed-blocks-queue. The aim is to defer as long as possible reallocation of this block. Until that happens, all attempts to access it will elicit an invalid-address error, as you would hope.

## 3.6. Client Requests

The following client requests are defined in `memcheck.h`. They also work for Addrcheck. See `memcheck.h` for exact details of their arguments.

- `VALGRIND_MAKE_NOACCESS`, `VALGRIND_MAKE_WRITABLE` and `VALGRIND_MAKE_READABLE`. These mark address ranges as completely inaccessible, accessible but containing undefined data, and accessible and containing defined data, respectively. Subsequent errors may have their faulting addresses described in terms of these blocks. Returns a "block handle". Returns zero when not run on Valgrind.

- `VALGRIND_DISCARD`: At some point you may want Valgrind to stop reporting errors in terms of the blocks defined by the previous three macros. To do this, the above macros return a small-integer "block handle". You can pass this block handle to `VALGRIND_DISCARD`. After doing so, Valgrind will no longer be able to relate addressing errors to the user-defined block associated with the handle. The permissions settings associated with the handle remain in place; this just affects how errors are reported, not whether they are reported. Returns 1 for an invalid handle and 0 for a valid handle (although passing invalid handles is harmless). Always returns 0 when not run on Valgrind.

- `VALGRIND_CHECK_WRITABLE` and `VALGRIND_CHECK_READABLE`: check immediately whether or not the given address range has the relevant property, and if not, print an error message. Also, for the convenience of the client, returns zero if the relevant property holds; otherwise, the returned value is the address of the first byte for which the property is not true. Always returns 0 when not run on Valgrind.

- `VALGRIND_CHECK_DEFINED`: a quick and easy way to find out whether Valgrind thinks a particular variable (lvalue, to be precise) is addressible and defined. Prints an error message if not. Returns no value.

- `VALGRIND_DO_LEAK_CHECK`: run the memory leak detector right now. Returns no value. I guess this could be used to incrementally check for leaks between arbitrary places in the program's execution. Warning: not properly tested!

- `VALGRIND_COUNT_LEAKS`: fills in the four arguments with the number of bytes of memory found by the previous leak check to be leaked, dubious, reachable and suppressed. Again, useful in test harness code, after calling `VALGRIND_DO_LEAK_CHECK`.

- `VALGRIND_GET_VBITS` and `VALGRIND_SET_VBITS`: allow you to get and set the V (validity) bits for an address range. You should probably only set V bits that you have got with `VALGRIND_GET_VBITS`. Only for those who really know what they are doing. Note: currently disabled in Valgrind 3.1.0.