Fix for bug #78048.
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 a5019735-40e9-0310-863c-91ae7b9d1cf9
diff --git a/memcheck/mac_shared.h b/memcheck/mac_shared.h
index d574203..06236dc 100644
--- a/memcheck/mac_shared.h
+++ b/memcheck/mac_shared.h
@@ -317,9 +317,9 @@
extern Bool MAC_(shared_recognised_suppression) ( Char* name, Supp* su );
-extern MAC_Chunk* MAC_(new_block) ( Addr p, UInt size, UInt rzB,
- Bool is_zeroed, MAC_AllocKind kind,
- VgHashTable table);
+extern void* MAC_(new_block) ( Addr p, UInt size, UInt align, UInt rzB,
+ Bool is_zeroed, MAC_AllocKind kind,
+ VgHashTable table);
extern void MAC_(handle_free) ( Addr p, UInt rzB, MAC_AllocKind kind );
extern void MAC_(create_mempool)(Addr pool, UInt rzB, Bool is_zeroed);