Subj : Re: Valgrind reported memory leak To : comp.programming.threads From : Paul Pluzhnikov Date : Thu Jun 09 2005 08:58 pm David Butenhof writes: > Yes, they ARE at fault for reporting that, and confusing the end > users. A single global allocation (usually on initialization but > sometimes later) that's needed for the life of the process and that's > EXPECTED (quite reasonably) to be eliminated by process rundown is NOT > (I repeat, with excessively redundant decoration ***NOT***) a leak. You may repeat this as many times as you want, but unless you *define* what is a leak and what isn't, it's hard to argue one way or the other. I think we may be able to agree that a leak is dynamically-allocated memory that could not possbly be free()d by the application. E.g. if (cond) { Foo *f = new Foo; ...; /* leave scope loosing "f" */ } The definition that leak detection tools often use is memory that the app has no pointers to. This is significantly bigger class, because the app may have a pointer to 12 bytes before the block, 50 bytes into the block, or 500 bytes after the block, and can still perform e.g. free((char*)block - block->size - 500). It is these kinds of "debugger-unfriendly" constructs that I am arguing against using. > Sometimes those pointers aren't > easy for an external leak detector to find; but more often it doesn't > even bother. If a dynamic allocation still EXISTS at rundown, it's > considered a leak. I know of no commercial leak detection tool that is so crude. All of the ones I've ever used *do* bother to separate allocations into "leaked" (no pointers), "potentially leaked" (a pointer somewhere into the block), and "in-use/outstanding" (there is a pointer to the beginning of the block, reachable from stack or globals). The end-users usually concentrate on the first category. Unfortunately, they often have to also examine the last category (e.g. because they have a data structure that grows forever without actually leaking anything, such as an ever-growing vector of strings), and that category often contains a lot of "one-time" allocations performed by "the system" at process startup. >> A runtime library that makes implementation of debugging >> tools difficult causes lack of such tools, causes developers to ... > And an OS that wastes seconds during process rundown cleaning up junk I agree. I agreed in the message you are replying to: >> Now, I agree that cleaning up all allocations is a bad idea. That doesn't invalidate my point though. Systems that are easier to debug on have a "developer advantage". Cheers, -- In order to understand recursion you must first understand recursion. Remove /-nsp/ for email. .