Robert Haas <robertmhaas@gmail.com> writes:
> On Wed, Jan 6, 2010 at 10:13 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Robert Haas <robertmhaas@gmail.com> writes:
>>> What tools do we have for identifying memory leaks?
>>
>> User complaints :-(
> YGTBFKM.
Not really. Given the memory context architecture, leaks are simply not
a big deal in 99% of the system. We just need a few coding rules like
"don't run random code in CacheMemoryContext" ;-)
> It seems like we should have a tool that dumps out every memory
> context in the system, with the number of allocations and frees and
> number of bytes allocated and freed since the last reset. Maybe the
> time of the last reset. You could run that before and after doing
> whatever it is that might leak and compare.
Once you've identified a place that "might leak" and a test case that
would exercise it, you've already done most of the work. What you're
describing sounds to me like a lot of work for not much return.
Furthermore, if you do have a leaking test case and you don't know
exactly where the leak is coming from, numbers about how big the leak is
aren't any help in finding the cause. What you really want is numbers
that are per palloc call site, which would not be simple to get. I have
occasionally wondered about hooking up something similar to valgrind for
this; but the problem is that it would drown you in false positives
because of the number of places where we intentionally leave stuff to be
cleaned up at context reset.
regards, tom lane