Nicholas Nethercote wrote: [snip] > It's a simplified version of a real problem, where a user implements a > custom allocator on top of malloc(). ...
> 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 0. Have a way for the custom allocator to say, "This interval will be used as an arena for custom allocation," and "This interval no longer will be used as such an arena." A custom allocator must tell memcheck these facts. If not then memcheck may adopt any policy at all, including random policy. 1. Overlap is allowed only for a custom arena and the blocks that it allocates. Arenas can nest. An arena can be cleared: all blocks free()d as a group in one operation without specifying each allocated block separately. 2. Each arena is considered to be its own root with respect to blocks that it allocates, and also each arena is considered to be an opaque allocated block within its nearest enclosing arena. Thus the leak report has a separate section for each arena, and an arena can be leaked within its nearest enclosing arena yet still contain its own non-leaked blocks. -- ------------------------------------------------------------------------------ _______________________________________________ Valgrind-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/valgrind-users
