Subj : Re: Valgrind reported memory leak To : comp.programming.threads From : David Butenhof Date : Thu Jun 09 2005 01:16 pm Sean Burke wrote: > "Peter Dimov" writes: > >>The leak is probably caused by a statically initialized mutex. One-time >>allocations that are never deallocated are typically harmless. "Leaking" >>usually refers to the process gradually eating an unbounded amount of >>memory. > > I once had a rather lengthy discussion with someone about > whether it would be a good idea to register an atexit() > handler to "fix" a "memory leak" similar to this one. Sigh. Yes, there was once a big push in Tru64 UNIX to make all of the runtime components "cleanly deallocate" ALL allocated memory at process rundown. Why? Simply so that memory leak detectors (and their users) wouldn't have to figure out what was really a leak and what wasn't. Stupid, stupid, stupid. Even if you could do it only when a leak detector is actually looking at the process, it's complicated and wasteful. And since in general there's no standard way to tell, it means doing this all the time. The whole bloody HOUSE is about to be demolished (by process rundown in the kernel); spending time, energy, and development time making sure you've dusted every corner first is utterly idiotic. 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 -- that's what it exists to do, and if it can't do that it's not the system's responsibility to work around it by wasting everyone's time and energy. -- 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 .