Re: shall we have a TRACE_MEMORY mode

Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> About the exact form we'd give the feature: maybe write each
> allocation/freeing to a per-backend file, say /tmp/pgmem.<pid>. Also
> memory context creation, destruction, reset. Having the __FILE__ and
> __LINE__ on each operation would be a good tracing tool as well. Then
> it's easy to write Perl tools to find specific problems.

That seems mostly the hard way to me, because our memory management
scheme is *not* based around "thou shalt free() what thou malloc()ed".
You'd need a tool that understood about resetting memory contexts
(recursively) to get anywhere at all in analyzing such a trace.

I've had some success in the past with debugging memory leaks by
trawling through the oversized memory contexts with gdb "x" and
trying to understand what the bulk of the data was. This is certainly
pretty painful though.

One idea that comes to mind is to have a compile time option to record
the palloc __FILE__ and _LINE__ in every AllocChunk header. Then it
would not be so hard to identify the culprit while trawling through
memory. The overhead costs would be so high that you'd never turn it on
by default though :-(

Another thing to consider is that the proximate location of the palloc
is frequently *not* very useful. For instance, if your memory is
getting eaten by lists, all the palloc traces will point at
new_tail_cell(). Not much help. I don't know what to do about that
... any ideas?

regards, tom lane