Subj : Re: Valgrind reported memory leak To : comp.programming.threads From : David Schwartz Date : Thu Jun 09 2005 09:14 pm "Paul Pluzhnikov" wrote in message news:m3slzqapfo.fsf@amoeba.parasoft.com... > 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. A leak is memory that has been allocated and lost track of. It is memory that can never be used or released by the process. > 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" */ } Or used by the application. If it's being actively used, it has not been leaked. > 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. It's reasonable for the tool to break if the user "deliberately" confuses it. You could, if you really wanted to, store a pointer to a block in a file and retrieve it later. DS .