On Sat, Jul 25, 2009 at 11:37 PM, John Reiser<[email protected]> wrote: > >> 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.
Hmm. That sounds a lot like the existing MEMPOOL client requests, except maybe for the nesting. And I just tested them and found they can handle the given program -- the strategy used is (1) -- any malloc'd block marked as a mempool is ignored by the leak checker. The MEMPOOL requests probably totally subsume MALLOCLIKE/FREELIKE. It's hard to tell without looking deeper as the documentation for the MEMPOOL requests is paltry. I imagine MALLOCLIKE/FREELIKE could be implemented in terms of MEMPOOL. I'll take a look. Thanks for the suggestion. Nick ------------------------------------------------------------------------------ _______________________________________________ Valgrind-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/valgrind-users
