From: Bart Van Assche Date: Fri, 26 Jun 2009 19:03:53 +0000 (+0000) Subject: Applied the patch attached to http://bugs.kde.org/show_bug.cgi?id=165468: fixed some... X-Git-Tag: svn/VALGRIND_3_5_0~465 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=06eb5d4a25fce309d6c10d8149520bc8b8b68515;p=thirdparty%2Fvalgrind.git Applied the patch attached to http://bugs.kde.org/show_bug.cgi?id=165468: fixed some formatting inconsistencies. git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10381 --- diff --git a/memcheck/docs/mc-manual.xml b/memcheck/docs/mc-manual.xml index 45c274f550..32c63083b3 100644 --- a/memcheck/docs/mc-manual.xml +++ b/memcheck/docs/mc-manual.xml @@ -17,8 +17,9 @@ is the default tool. 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: +malloc/new/free/delete +are intercepted. As a result, Memcheck can detect the following +problems: @@ -38,8 +39,10 @@ the following problems: lost forever - Mismatched use of malloc/new/new [] vs - free/delete/delete [] + Mismatched use of + malloc/new/new[] + versus + free/delete/delete[] Overlapping src and @@ -189,7 +192,8 @@ the following problems: When the client program releases memory using - free (in C) or delete + 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 @@ -399,9 +403,10 @@ complains. 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. + 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. @@ -427,12 +432,14 @@ Invalid free() 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 +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. @@ -618,8 +625,9 @@ implementation. 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. +calls to +malloc/calloc/realloc/new. +So when the program exits, it knows which blocks have not been freed. If is set appropriately, for each @@ -1031,10 +1039,11 @@ themselves do not change the A bits, only consult them. - 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 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. @@ -1142,43 +1151,53 @@ follows: -Memcheck intercepts calls to malloc, calloc, realloc, valloc, -memalign, free, new, new[], delete and delete[]. The behaviour you get +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 addressable - but not having valid values. This means you have to write to it - before you can read it. + malloc/new/new[]: + the returned memory is marked as addressable but not having valid + values. This means you have to write to it before you can read + it. - calloc: returned memory is marked both addressable and valid, - since calloc clears the area to zero. + calloc: returned memory is marked both + addressable and valid, since calloc clears + the area to zero. - realloc: if the new size is larger than the old, the new - section is addressable but invalid, as with malloc. + realloc: if the new size is larger than + the old, the new section is addressable but invalid, as with + malloc. - If the new size is smaller, the dropped-off section is marked - as unaddressable. You may only pass to realloc a pointer previously - issued to you by malloc/calloc/realloc. + If the new size is smaller, the dropped-off section is + marked as unaddressable. 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, Memcheck complains. If the pointer is indeed - valid, Memcheck marks the entire area it points at as unaddressable, - 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. + free/delete/delete[]: + you may only pass to these functions a pointer previously issued + to you by the corresponding allocation function. Otherwise, + Memcheck complains. If the pointer is indeed valid, Memcheck + marks the entire area it points at as unaddressable, 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. @@ -1326,7 +1345,9 @@ systems: Typically the pool's chunks are drawn from a contiguous - "superblock" acquired through the system malloc() or mmap(). + "superblock" acquired through the system + malloc() or + mmap(). @@ -1460,22 +1481,23 @@ inform Memcheck about changes to the state of a mempool: - VALGRIND_MOVE_MEMPOOL(poolA, poolB): - This request informs Memcheck that the pool previously anchored at - address "poolA" has moved to anchor address "poolB". This is a rare - request, typically only needed if you realloc() the header of - a mempool. + VALGRIND_MOVE_MEMPOOL(poolA, poolB): This + request informs Memcheck that the pool previously anchored at + address "poolA" has moved to anchor address "poolB". This is a + rare request, typically only needed if you + realloc() the header of a mempool. No memory-status bits are altered by this request. - VALGRIND_MEMPOOL_CHANGE(pool, addrA, addrB, size): - This request informs Memcheck that the chunk previously allocated at - address "addrA" within "pool" has been moved and/or resized, and should - be changed to cover the region [addrB,addrB+size). This is a rare - request, typically only needed if you realloc() a superblock or wish - to extend a chunk without changing its memory-status bits. + VALGRIND_MEMPOOL_CHANGE(pool, addrA, addrB, + size): This request informs Memcheck that the chunk + previously allocated at address "addrA" within "pool" has been + moved and/or resized, and should be changed to cover the region + [addrB,addrB+size). This is a rare request, typically only needed + if you realloc() a superblock or wish to + extend a chunk without changing its memory-status bits. No memory-status bits are altered by this request.