From: Nicholas Nethercote Date: Wed, 5 Aug 2009 07:15:28 +0000 (+0000) Subject: Tweaks to Ptrcheck's manual chapter. X-Git-Tag: svn/VALGRIND_3_5_0~132 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=368c05d77d5e9787409e229404c8e25bf59e93cc;p=thirdparty%2Fvalgrind.git Tweaks to Ptrcheck's manual chapter. git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10718 --- diff --git a/exp-ptrcheck/docs/pc-manual.xml b/exp-ptrcheck/docs/pc-manual.xml index f3eb6acaa6..e9a2137764 100644 --- a/exp-ptrcheck/docs/pc-manual.xml +++ b/exp-ptrcheck/docs/pc-manual.xml @@ -49,7 +49,7 @@ known, is entirely novel. Ptrcheck Options -The following end-user options are available: +Ptrcheck-specific options are: @@ -97,26 +97,6 @@ known, is entirely novel. - -In addition, the following debugging options are available for -Ptrcheck: - - - - - - - - - Show all client malloc (etc) and free (etc) requests. - - - - - - - @@ -138,19 +118,19 @@ bounds of the associated block, and reports an error if the address is out of bounds, or if the block has been freed. Of course it is rarely the case that one wants to access a block -only at the exact address returned by malloc (et al). Ptrcheck -understands that adding or subtracting offsets from a pointer to a +only at the exact address returned by malloc et al. +Ptrcheck understands that adding or subtracting offsets from a pointer to a block results in a pointer to the same block. At a fundamental level, this scheme works because a correct program cannot make assumptions about the addresses returned by -malloc. In particular it cannot make any assumptions about the -differences in addresses returned by subsequent calls to malloc. -Hence there are very few ways to take an address returned by malloc, -modify it, and still have a valid address. In short, the only -allowable operations are adding and subtracting other non-pointer -values. Almost all other operations produce a value which cannot -possibly be a valid pointer. +malloc et al. In particular it cannot make any +assumptions about the differences in addresses returned by subsequent calls +to malloc et al. Hence there are very few ways to take +an address returned by malloc, modify it, and still +have a valid address. In short, the only allowable operations are adding +and subtracting other non-pointer values. Almost all other operations +produce a value which cannot possibly be a valid pointer. @@ -171,12 +151,10 @@ memory referencing instruction was supposed to access. Unfortunately the DWARF3 debugging format does not provide a way to represent such information, so we have to resort to a heuristic technique to approximate the same information. The key observation is that - - - + if a memory referencing instruction accesses inside a stack or global array once, then it is highly likely to always access that - same array + same array. To see how this might be useful, consider the following buggy fragment: @@ -199,19 +177,20 @@ Ptrcheck reports an error. There is an important caveat. -Imagine a function such as memcpy, which is used to read and -write many different areas of memory over the lifetime of the program. -If we insist that the read and write instructions in its memory -copying loop only ever access one particular stack or global variable, -we will be flooded with errors resulting from calls to memcpy. +Imagine a function such as memcpy, which is used +to read and write many different areas of memory over the lifetime of the +program. If we insist that the read and write instructions in its memory +copying loop only ever access one particular stack or global variable, we +will be flooded with errors resulting from calls to +memcpy. To avoid this problem, Ptrcheck instantiates fresh likely-target records for each entry to a function, and discards them on exit. This -allows detection of cases where (eg) memcpy overflows its source or -destination buffers for any specific call, but does not carry any -restriction from one call to the next. Indeed, multiple threads may -be multiple simultaneous calls to (eg) memcpy without mutual -interference. +allows detection of cases where (e.g.) memcpy overflows +its source or destination buffers for any specific call, but does not carry +any restriction from one call to the next. Indeed, multiple threads may be +multiple simultaneous calls to (e.g.) memcpy without +mutual interference. @@ -244,8 +223,8 @@ of the process' address space. Ptrcheck's approach is to keep track of pointers derived from heap blocks. It tracks pointers which are derived directly from calls -to malloc et al, but also ones derived indirectly, by adding or -subtracting offsets from the directly-derived pointers. When a +to malloc et al, but also ones derived indirectly, by +adding or subtracting offsets from the directly-derived pointers. When a pointer is finally used to access memory, Ptrcheck compares the access address with that of the block it was originally derived from, and reports an error if the access address is not within the block @@ -275,17 +254,16 @@ will require only 320MB of extra storage. Achieving the same level of detection with Memcheck is close to impossible and would likely involve several gigabytes of extra storage. -In defense of Memcheck ... - -Remember that Memcheck performs uninitialised value checking, -which Ptrcheck does not. Memcheck has also benefitted from years of -refinement, tuning, and experience with production-level usage, and so -is much faster than Ptrcheck as it currently stands, as of October -2008. +Having said all that, remember that Memcheck performs uninitialised +value checking, invalid and mismatched free checking, overlap checking, and +leak checking, none of which Ptrcheck do. Memcheck has also benefitted from +years of refinement, tuning, and experience with production-level usage, and +so is much faster than Ptrcheck as it currently stands. + -Consequently it is recommended to first make your programs run -Memcheck clean. Once that's done, try Ptrcheck to see if you can -shake out any further heap, global or stack errors. +Consequently we recommend you first make your programs run Memcheck +clean. Once that's done, try Ptrcheck to see if you can shake out any +further heap, global or stack errors. @@ -323,20 +301,21 @@ of. Heap checks: Ptrcheck needs to "understand" which system calls return pointers and which don't. Many, but not all system - calls are handled. If an unhandled one is encountered, Ptrcheck - will abort. + calls are handled. If an unhandled one is encountered, Ptrcheck will + abort. Fortunately, adding support for a new syscall is very + easy. - Stack checks: It follows from the description above (How Ptrcheck - Works: Stack and Global Checks) that the first access by a memory - referencing instruction to a stack or global array creates an - association between that instruction and the array, which is - checked on subsequent accesses by that instruction, until the - containing function exits. Hence, the first access by an - instruction to an array (in any given function instantiation) is - not checked for overrun, since Ptrcheck uses that as the "example" - of how subsequent accesses should behave. + Stack checks: It follows from the description above () that the first access by a + memory referencing instruction to a stack or global array creates an + association between that instruction and the array, which is checked on + subsequent accesses by that instruction, until the containing function + exits. Hence, the first access by an instruction to an array (in any + given function instantiation) is not checked for overrun, since Ptrcheck + uses that as the "example" of how subsequent accesses should + behave. @@ -393,9 +372,9 @@ of. Coverage: the heap checking is relatively robust, requiring - only that Ptrcheck can see calls to malloc/free et al. In that - sense it has debug-info requirements comparable with Memcheck, and - is able to heap-check programs even with no debugging information + only that Ptrcheck can see calls to malloc et al. + In that sense it has debug-info requirements comparable with Memcheck, + and is able to heap-check programs even with no debugging information attached. Stack/global checking is much more fragile. If a shared @@ -424,7 +403,7 @@ of. PowerPC platforms, only on x86 and amd64 targets. That's because the stack and global checking requires tracking function calls and exits reliably, and there's no obvious way to do it with the PPC - ABIs. (cf with the x86 and amd64 ABIs this is relatively + ABIs. (In comparison, with the x86 and amd64 ABIs this is relatively straightforward.) @@ -444,8 +423,8 @@ of. -Still To Do: User Visible Functionality + xreflabel="Still To Do: User-visible Functionality"> +Still To Do: User-visible Functionality @@ -494,7 +473,7 @@ in real use. - h_main.c: move vast amounts of arch-dependent uglyness + h_main.c: move vast amounts of arch-dependent ugliness (get_IntRegInfo et al) to its own source file, a la mc_machine.c. @@ -519,7 +498,7 @@ in real use. sg_main.c: fix compute_II_hash to make it a bit more sensible for ppc32/64 targets (except that sg_ doesn't work on ppc32/64 - targets, so this is a bit academic at the mo). + targets, so this is a bit academic at the moment).