>> It is possible to add macros to the code to help valgrind know which
>> areas are being used by a custom allocator. (See
>> VALGRIND_MALLOCLIKE_BLOCK and VALGRIND_FREELIKE_BLOCK, for example.)
>> I'm not sure if they're useful in this situation, but they're worth
>> taking a look at.
>> I see. That would discover errors such as something overwriting
> structures allocated by the allocator but that were not handled to the
> application, right?
>> Is there any reason why that's not included in the webkit allocator? I
> mean apart from lack of time/interest, of course.
I don't think that would be useful. Real allocators do several
optimizations, which could hide many errors. An example:
p = malloc(100);
free(p);
p = malloc(100);
I clever allocator would probably return with the same pointer. However,
valgrind wants to detect unintended access to freed blocks, so its
allocator would never reuse the same address if possible. Moreover, it
skips X bytes before and after the block to detect overwrite / underwrite
situations (red zones). Thus, we should use the system malloc if possible
(captured and redirected by valgrind). And leave that macro to those
cases, where the software is designed to not use system malloc (garbage
collected memory areas for example).
Regards,
Zoltan