| From: | "Qingqing Zhou" <zhouqq(at)cs(dot)toronto(dot)edu> |
|---|---|
| To: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: shall we have a TRACE_MEMORY mode |
| Date: | 2006-06-21 02:20:08 |
| Message-ID: | e7aacp$1qim$1@news.hub.org |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
"Alvaro Herrera" <alvherre(at)commandprompt(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Martijn van Oosterhout | 2006-06-21 06:43:56 | Re: trivial DoS on char recoding |
| Previous Message | Bruce Momjian | 2006-06-21 00:45:10 | My new email address |