|
From: Robert W. <rj...@du...> - 2009-08-18 20:31:14
|
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.) Valgrind doesn't have a solution for this scenario, either, and I doubt we ever will. 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. 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. Regards, Robert. On Tue, Aug 18, 2009 at 7:15 AM, Stuart Warren <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...> > 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... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > |