* Redzones for custom alloc were not protected by VALGRIND_MALLOCLIKE_BLOCK.
mc_main.c client request handling completed with protection
of the redzones.
* custom_alloc.c test modified to test this case.
* mc_errors.c modified so as to first search for a malloc-ed block
bracketting the error : for a custom allocator, a recently freed
block can have just been re-allocated.
In such a case, describing the address (e.g. in case of error)
points to the block freed rather than to the block just allocated.
If there is *also* a recently freed block bracketting the address,
the block description is changed to indicate that.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12439
overhaul of the thread support. Many things are now probably broken,
but at least with --tool=none, simple and not-so-simple threaded and
non-thread programs work.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3265
Address 0x%x is not stack'd, malloc'd or free'd
to
Address 0x%x is not stack'd, malloc'd or (recently) free'd
This makes things clearer in some circumstances, particularly when bogusly
accessing heap memory that has been freed, but Memcheck is no longer tracking.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2358
indented one space; previously it was mixed, but Memcheck/Addrcheck indented
"Address" lines 3, which made them hard to see in the stack trace.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2021
option --show-below-main is on. It's on by default. It also affects
suppressions generated with --gen-suppressions=yes. Updated reg tests
accordingly.
Also updated docs for this. And added some missing command-line args to docs.
Also compartmentalised the options a little in the docs, and rearranged the
order of options in the usage message, in anticipation of a bigger
rearrangement that will be necessary soon -- to distinguish options used by all
skins from those used by error-checking skins, to skin-specific ones.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2020
use a custom-allocator and detect almost as many errors as you could detect if
you used malloc/new/new[]. (eg. leaks detected, free errors, free mismatch,
etc).
Had to fiddle with mac_malloc_wrappers.c a bit to factor out the appropriate
code to be called from the client request handling code. Also had to add a
new element `MAC_AllocCustom' to the MAC_AllocKind type.
Also added a little documentation, and a regression test.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1643
