|
From: Nicholas N. <n.n...@gm...> - 2009-07-24 21:12:48
|
Hi, https://bugs.kde.org/show_bug.cgi?id=100628 concerns a program like this: #include <stdlib.h> #include "valgrind.h" int main(void) { char* x; x = malloc(1000); VALGRIND_MALLOCLIKE_BLOCK(x, /*szB*/ 16, /*rzB*/0, /*is_zeroed*/0); VALGRIND_MALLOCLIKE_BLOCK(x+100, /*szB*/ 32, /*rzB*/0, /*is_zeroed*/0); VALGRIND_MALLOCLIKE_BLOCK(x+200, /*szB*/ 64, /*rzB*/0, /*is_zeroed*/0); VALGRIND_MALLOCLIKE_BLOCK(x+300, /*szB*/128, /*rzB*/0, /*is_zeroed*/0); return 0; } It's a simplified version of a real problem, where a user implements a custom allocator on top of malloc(). They use malloc() to allocate a big chunk of memory, and then hand out pieces of it, using MALLOCLIKE_BLOCK to mark those pieces as logically separate heap blocks. Currently the leak checker barfs on it because it can't handle overlapping heap blocks. I have a patch that tolerates overlaps such as these, where a custom block falls entirely within a malloc()'d block. But there's a design choice to be made. In such a case, what do we do with the malloc()'d block? (1) Ignore it completely when leak checking (2) Consider it when leak checking It's unclear to me which of these is preferable. (1) treats the malloc() much as a mmap() or brk() would be treated, which is arguably desirable, as many allocators are built on mmap() and/or brk() and so treating malloc() in the same way makes some sense. But (2) involves less special-casing, and is thus slightly easier to do than (1). Anyone have any preferences? Nick |