Menu
▾
▴
Re: [Valgrind-developers] Leak checking mempools
|
From: Stuart W. <de...@ra...> - 2009-08-18 22:29:07
|
Robert Walsh wrote: > You can make the exact same argument about someone that sticks all > their mallocs onto a linked list and frees them at a later time (I've > seen people do this because of some memory crashers they couldn't fix, > so they took the nuclear approach as a workaround.) Yep. This is a similar pattern to your pool example where allocations from the pool are released in one go (doesn't matter if it's through the release of the pool's superblock(s) or by traversing the linked list and calling free on each allocation). If both cases you no longer care about leaks. But I'm not saying MEMPOOLs should always be leak checked when destroyed (but it _was_ one of the three ways I was proposing to improve MEMPOOL leak reporting) . It's up to the person using the MEMPOOL instrumentation to decide what fits with their custom allocator. > Valgrind doesn't have a solution for this scenario, either, and I > doubt we ever will. Agree. I don't think there needs to be a solution - memcheck helps them fix their bugs before they resort to desperation :). > > What does VALGRIND_DO_LEAK_CHECK do for you? I've never used it, but > it should consider your mempools and their contents. If it doesn't, > then that's a bug. > VALGRIND_DO_LEAK_CHECK considers all malloc'd allocations and existing MEMPOOLS. It gives a lot of false positives. Maybe I am using it incorrectly, but I can't see how. > If that's not what you want, then since none of us really understand > what you're trying to solve, please implement a patch and send it to > the list for consideration - maybe the code will make it clearer. > Good idea. Originally I had three ways of doing the leak checking. Thanks to you and Nick, I'm down to one - VALGRIND_MEMPOOL_DO_LEAK_CHECK. It's patch o'clock... Thanks! Cheers, Stu > Regards, > Robert. > > On Tue, Aug 18, 2009 at 7:15 AM, Stuart Warren <de...@ra... > <mailto:de...@ra...>> wrote: > > Hi Nick and Robert, > > I've already replied to both of you on this, but for the sake of the > mailing list... > > I agree with you both (I've put a comment in about mmap usage > below). I > get that freeing the mempool means there aren't any leaks. Exiting an > application means there are no leaks too, but we still leak check > malloc > just before it is destroyed. It's the same thing, only the > lifetimes of > the allocators are different. If the memcheck's malloc leak detection > were implemented using the MEMPOOL interface (which is what it is > designed to do), what would you do just before the pool was destroyed? > Report leaks right? > > Leaks _within_ the lifetime of the MEMPOOL can cause problems for > software. If memory hasn't been returned to the pool before it is > destroyed, it is possible it's because of a software problem - it > depends on what the MEMPOOL interface is being used for. The MEMPOOL > documentation makes it clear that it tries to make as few > assumptions as > possible on how custom allocators should work - but the implementation > assumes no one wants to leak check in this way. > > I am suggesting there should be a way to trigger a leak report for a > mempool (rather than for everything). If people want to get a leak > report before a pool is destroyed, Robert's example becomes: > > VALGRIND_MEMPOOL_DO_LEAK_CHECK(X); > free(X); > > This extends the flexibility of the MEMPOOL concept. It doesn't alter > the way the existing client requests work. > > Cheers, > Stu > > Nicholas Nethercote wrote: > > On Tue, Aug 18, 2009 at 4:41 AM, Robert > Walsh<rj...@du... <mailto:rj...@du...>> wrote: > > > >> > >> To free the pool itself, you do: > >> > >> free(X); > >> > > > > Which implicitly frees any blocks within the pool that haven't > yet been freed. > > > >> So, given the above terminology, can you please clarify what > the behavior of > >> your program is and what you expect Valgrind to show. Here's > what Valgrind > >> should do: > >> > >> If you allocate a pool X, allocate no memory from it and then > free X, > >> Valgrind will report no leaked memory. > >> > > > > Yes. > > > > > >> If you allocate a pool X, allocate no memory from it and do not > free X, > >> Valgrind will report X as leaked memory. > >> > > > > Yes. > > > > > >> If you allocate a pool X, allocate memory Y from the pool, do > not free Y and > >> do not free X, Valgrind will report both X and Y as leaked memory. > >> > > > > I thought it would report only Y as leaked, because within-pool > > allocations override whole-pool allocations in the leak checker (see > > find_active_chunks() in memcheck/mc_leakcheck.c). > > > Agree with Nick - only Y is reported as leaked. However if X was > mmap'd, no leak is reported. The leak report should be the same > whether > the pool was malloc'd or mmap'd. > >> If you allocate a pool X, allocate memory Y from the pool, do > not free Y but > >> do free X, Valgrind will report no memory leaked. > >> > > > > Yes, because freeing X implicitly frees Y. > > > . > >> If you allocate a pool X, allocate memory Y from the pool, free > Y but do not > >> free X, Valgrind will report X as leaked memory, but will not > report Y as > >> leaked memory. > >> > > > > Yes. > > > > > >> Is this behavior different to what you expect? Can you elaborate? > >> > > > > Thanks for clarifying! > > > > Nick > > > > > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports > 2008 30-Day > trial. Simplify your report design, integration and deployment - > and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > <mailto:Val...@li...> > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > > |
