Subj : Re: Valgrind reported memory leak To : comp.programming.threads From : David Butenhof Date : Thu Jun 09 2005 07:47 pm Paul Pluzhnikov wrote: > Maciej Sobczak writes: > > >>David Butenhof wrote: >> >> >>>Detecting and fixing dynamic memory leaks is a great idea. But while >>>I recognize that its difficult for a tool to distinguish static from >>>dynamic, that's its job > > The tools job is to report what's leaked. Exactly. > When the runtime libraries leak their "internal" buffers, the tools > aren't really at fault for reporting that, but it does make it more > difficult for the end-users to interpret the results. 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. > Now, I agree that cleaning up all allocations is a bad idea. > But at least having a "live" global reference to the data, so that > it is reported as "outstanding" rather then outright "leaked" > would go a long way to help the end user. It is outstanding until process termination, by definition. No more is necessary. And mostly these allocations do indeed have live pointers at termination, though they may be indirect (for example a queue of cached "thread structures" for reuse). 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. Registering and tracking all possible such allocations in a complex system is difficult, and of value to nobody really but the tools. If a vendor tried to do this alone, most 3rd party tools probably wouldn't even use it because the mechanism would be proprietary and they couldn't use it elsewhere anyway. If an OS/library vendor has its own leak tracker and choose to expend their resources solving the problem that way, fine; but they may not necessarily document it for anyone else anyway. (After all, it's an expensive competitive advantage!) >>Moreover, it is a business oportunity and an arena for competition >>between leak detectors. Let them fix themselves for the their own >>benefit. > > They aren't really broken (unless they report bogus leaks). Right. And since these aren't leaks, they're either broken or they've already solved the problem. (Does it help any to know that? ;-) ) > The vendors could provide a default set of suppressions for "known > system leaks". The trouble is that this list changes with various > patch levels, depends on which libraries the user links against, > and in what order, etc. etc. Quite difficult to create and maintain, probably obscure to use, and certainly non-portable. I've got an idea -- instead of complaining, organize a standards working group to get tool and OS developers together and agree on a way to do this reliably and portably without unreasonable runtime burden on anyone. (Warning: diagnostic functions, including debugging of any sort, are generally not part of standards because OS and tool implementations vary so radically that common ground is inordinately difficult to identify.) >>The issue is not only about pthread functions. There are other >>run-time (system!) functions that tend to pop up in leak reports, so >>indeed it would be too much effor to "fix" the whole world just to >>make the diagnostic tools happy. > > It's not about making the tools happy. It's about making the *users* > happy. > > A runtime library that makes implementation of debugging > tools difficult causes lack of such tools, causes developers to > switch to more friendly OSes, and eventually contibutes to the > death of the "difficult" OS, even though it may have been better > in all other respects :-( And an OS that wastes seconds during process rundown cleaning up junk (and racking up pagefaults) just because that might someday make a leak tracker happy isn't going to please its users much either. -- Dave Butenhof, David.Butenhof@hp.com HP Utility Pricing software, POSIX thread consultant Manageability Solutions Lab (MSL), Hewlett-Packard Company 110 Spit Brook Road, ZK2/3-Q18, Nashua, NH 03062 .