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
------------------------------------------------------------------------------
_______________________________________________
Valgrind-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
