Re: shall we have a TRACE_MEMORY mode - Mailing list pgsql-hackers

From Tom Lane
Subject Re: shall we have a TRACE_MEMORY mode
Date
Msg-id 27435.1150810921@sss.pgh.pa.us
Whole thread Raw
In response to Re: shall we have a TRACE_MEMORY mode  (Alvaro Herrera <alvherre@commandprompt.com>)
List pgsql-hackers
Alvaro Herrera <alvherre@commandprompt.com> writes:
> Simon Riggs wrote:
>> Could we set that as an option for each memory context when we create
>> it? All or nothing seems too extreme for me for most cases.

> What most cases?  There is only one case -- there is a big leak and you
> want to find out where.

There's a more significant reason why not, which is that all AllocChunks
must have the same header, else pfree doesn't know what to do.

>> 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.

> Of course.  It's not difficult to do that; just tedious.  I wrote such a
> tool to debug a Mammoth Replicator problem (I don't think I've kept it
> though).  The logging code must emit messages about context creation,
> destruction and reset, and have the alloc message indicate what context
> is the chunk being created on.

Well, the logging approach would definitely be less intrusive to the
system's runtime behavior, and would (maybe) not require gdb to use.
If you can resurrect that tool it'd be interesting to look at.  Maybe
it's on a backup tape somewhere?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Martijn van Oosterhout
Date:
Subject: Re: shall we have a TRACE_MEMORY mode
Next
From: Tom Lane
Date:
Subject: Re: sync_file_range()