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.
