heap blocks. The minimum size for redzones is now sizeof(void*), but
I forgot to ensure this. Massif was asking for 0 byte redzones, and this
was screwing things up on 64-bit platforms, and Massif was dying very
quickly. This should fix bugs #111090 and #111285.
The fact that Massif was this badly broken but there were only 2 bug reports
indicates that not many people are using it, at least not on AMD64.
I also added a regtest that does some basic malloc/realloc/free testing
for Massif, which would have caught this problem.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4492
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
string in valgrind.pc.in, so that they describe Valgrind as a "dynamic
binary instrumentation framework", and don't mention platforms at all.
I had to tweak the regtest filters a bit for this.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3178
Problem was that the malloc-replacing tools (memcheck, addrcheck, massif,
helgrind) would assert if a too-big malloc was attempted. Now they return 0 to
the client. I also cleaned up the code handling heap-block-metadata in Massif
and Addrcheck/Memcheck a little.
This exposed a nasty bug in VG_(client_alloc)() which wasn't checking if
find_map_space() was succeeding before attempting an mmap(). Before I added
the check, very big mallocs (eg 2GB) for Addrcheck were overwriting the client
space at address 0 and causing crashes.
Added a regtest to all the affected skins for this.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2462
created by the test. Added appropriate lines to the Cachegrind and Massif
tests. Should prevent large numbers of files clogging up directories.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2372
