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_needs.c b/memcheck/mac_needs.c
index f2c8dc4..ce09679 100644
--- a/memcheck/mac_needs.c
+++ b/memcheck/mac_needs.c
@@ -880,8 +880,8 @@
UInt rzB = arg[3];
Bool is_zeroed = (Bool)arg[4];
- MAC_(new_block) ( p, sizeB, rzB, is_zeroed, MAC_AllocCustom,
- MAC_(malloc_list) );
+ MAC_(new_block) ( p, sizeB, /*ignored*/0, rzB, is_zeroed,
+ MAC_AllocCustom, MAC_(malloc_list) );
return True;
}
case VG_USERREQ__FREELIKE_BLOCK: {