|
From: Bart V. A. <bar...@gm...> - 2009-07-25 05:11:17
|
On Fri, Jul 24, 2009 at 11:12 PM, Nicholas Nethercote <n.n...@gm...> wrote: > 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? My suggestion is to require that the user makes it clear to Valgrind that the memory allocated by the malloc() call in the example won't be used directly but will be handed out in pieces to the client program. Bart. |