|
From: Stuart W. <de...@ra...> - 2009-08-16 21:13:03
|
Nicholas Nethercote wrote: > > I still don't understand. If a pool has been destroyed, all the > > blocks allocated from the pool have been freed. What leak checking is > > there to do? > > > The documentation says Valgrind mempool interface exists to support custom memory allocators (not just memory pools). It's just as valid to leak check allocations from custom allocators as it is from malloc and friends. For regular memory allocation we get to use VALGRIND_DO_LEAK_CHECK. There's no equivalent function for mempools. It seems natural that if there's an interface for tracking 'memory pools' with Valgrind, there should be a way of reporting their leaks. Anything that can be done for tracking malloc allocations should be able to be done with mempools. > > Yes. See http://www.valgrind.org/support/features.html. > > > > > Thanks for that. Reading it doesn't give me a lot of hope. I get the impression the mempool interface isn't widely used. The feature request is unlikely have any backers. Cheers, Stu Nicholas Nethercote wrote: > On Thu, Aug 13, 2009 at 10:20 PM, Stuart Warren<de...@ra...> wrote: > >> Thanks for that Nicholas. I agree with you that the test is working as >> documented but it's odd that the mempool code doesn't support leak >> checking for destroyed pools. It's not a lot of work to support this, >> it's more a matter of how. >> > > I still don't understand. If a pool has been destroyed, all the > blocks allocated from the pool have been freed. What leak checking is > there to do? > > >> I was going to raise a bug and attach the patch. Is that the best way >> for a casual contributor to get a change into Valgrind? >> > > Yes. See http://www.valgrind.org/support/features.html. > > Nick > > |