Subj : Re: Valgrind reported memory leak To : comp.programming.threads From : Paul Pluzhnikov Date : Thu Jun 09 2005 09:53 am 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. 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. 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. > 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). 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. > 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 :-( Cheers, -- In order to understand recursion you must first understand recursion. Remove /-nsp/ for email. .