On Sonntag 06 Januar 2008, Peter Oberndorfer wrote:
>
> VALGRIND_DISCARD is used to discard block description handles
> (which are created by VALGRIND_CREATE_BLOCK)
> but it was called with the return value of VALGRIND_MAKE_xxx macros
> which all return 0xffffffff
> dlls/ntdll/signal_i386.c uses this macros already without VALGRIND_DISCARD
> ---
> dlls/ntdll/heap.c | 16 ++++++++--------
> 1 files changed, 8 insertions(+), 8 deletions(-)
>
Please don't apply this yet, it needs further research.
The valgrind manual tells us in the Client Requests section
that VALGRIND_MAKE_xxx functions return such a block handle [1],
But looking at the implementation of valgrind/adding traces to valgind DISCARD request
show it returns 0xffffffff ?
Greetings Peter
[1] valgrind manual Release 3.3.0 - 4.6. Client Requests
* VALGRIND_MAKE_MEM_NOACCESS, VALGRIND_MAKE_MEM_UNDEFINED and VALGRIND_MAKE_MEM_DE
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_MAKE_MEM_DEFINED_IF_ADDRESSABLE. This is just like VALGRIND_MAKE_MEM_DEFINED
but only affects those bytes that are already addressable.
* 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.