|
From: Jeremy F. <je...@go...> - 2005-01-19 22:50:38
|
Hi all, Is anyone using VALGRIND_MALLOCLIKE_BLOCK/FREELIKE_BLOCK? If so, how? It seems to me that these requests are basically useless, because there's no way for Valgrind to tell when your malloc implementation is manipulating its metadata, and when the client is trashing it. If you mark your memory regions returned by your malloc-like function, Valgrind will complain when you touch memory near it with your free-like function. I think we need to add another pair of requests, VALGRIND_ENTER_MALLOCLIKE_FUNCTION/LEAVE_MALLOCLIKE_FUNCTION, which tells Valgrind not to complain about touching memory outside of blocks which have been declared MALLOCLIKE. J |
|
From: Nicholas M. L. <nm...@cs...> - 2005-01-24 02:39:48
|
hi, On Wed, Jan 19, 2005 at 02:47:25PM -0800, Jeremy Fitzhardinge wrote: > Is anyone using VALGRIND_MALLOCLIKE_BLOCK/FREELIKE_BLOCK? yes, i'm using them for custom allocators that i wrote. > If so, how? > > It seems to me that these requests are basically useless, because > there's no way for Valgrind to tell when your malloc implementation is > manipulating its metadata, and when the client is trashing it. If you > mark your memory regions returned by your malloc-like function, Valgrind > will complain when you touch memory near it with your free-like > function. the way i get around this is to only mark the regions i return for client use using MALLOCLIKE, and i only do that immediately prior to returning it. When the region is free'd i immediately call FREELIKE on it. I protect my meta-data seperately by marking it NOACCESS when my functions aren't manipulating it. That way, the MALLOCLIKE and FREELIKE requests are only used to manipulate the leak-checking, not memory protection. Its a bit tricky to ensure that i mark things accessible and inaccessible at the right times, but it was the only way i could find to get the intergration with valgrind that i wanted. > I think we need to add another pair of requests, > VALGRIND_ENTER_MALLOCLIKE_FUNCTION/LEAVE_MALLOCLIKE_FUNCTION, which > tells Valgrind not to complain about touching memory outside of blocks > which have been declared MALLOCLIKE. i certainly agree that the existing MALLOC functions are pretty quirky, (i still don't know whether the redzones come before or after the allocated block), and the MEMPOOL stuff i tried to understand but couldn't. But i did manage to get my allocator working so that i was happy with it in the end. cheers Nick |