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

From Qingqing Zhou
Subject Re: shall we have a TRACE_MEMORY mode
Date
Msg-id e7aacp$1qim$1@news.hub.org
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> wrote
>
> But the problem (or at last a part of the problem) is not what context
> each chunk is allocated in, but where did a given chunk come from (where
> was it allocated), Which is why saving __FILE__/__LINE__ is useful.
>

Agreed. Maybe we should not clutter these trace info in the AllocChunkData.
We save them in a separe memory context which is only activated when
TRACE_MEMORY is on. Also, recording every __FILE__/__LINE__ seems not
neccessary,  we merge them and record the count of calls. Once a leak is
happened, the usual suspect is the high-count one.

So the output of memory context dump will be looks like this:
   execQual.c     1953    123456   execHash.c     208       12   ...

>
> #ifdef TRACE_MEMORY
> #define lappend(_list_, _elt_) \
> lappend_tracemem(_list_, _elt_, __FILE__, __LINE__)
> #endif
>

This might be the only portable way I could think of. We don't want to
redefine all of the functions calling palloc()/MemoryContextAlloc(), we
redefine the most suspectable ones like those in heaptuple.c.

Regards,
Qingqing




pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: My new email address
Next
From: Martijn van Oosterhout
Date:
Subject: Re: trivial DoS on char recoding