Re: shall we have a TRACE_MEMORY mode

From: Martijn van Oosterhout <kleptog(at)svana(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Qingqing Zhou <zhouqq(at)cs(dot)toronto(dot)edu>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: shall we have a TRACE_MEMORY mode
Date: 2006-06-20 13:14:09
Message-ID: 20060620131409.GA25678@svana.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jun 20, 2006 at 12:18:32AM -0400, Tom Lane wrote:
> 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?

GCC has __builtin_return_address (LEVEL) which returns the frame
address of the LEVELth caller (on systems where this is possible). You
could perhaps track the caller and the callers caller.

glibc comes with a function called backtrace(0 which can be used to
grab several levels simultaneously. You can use dladdr() to turn these
into useful addresses.

These are probably not portable, on the whole.

As for overhead, maybe you can deal with that by only tracing blocks
that exceed a megabyte or more. Perhaps a small test:

if( increasing size of context over 10 MB )
dump_stack_trace()

Ofcourse, you might just miss the allocations you need to look at...
The backtrace_symbols_fd() function dumps straight to a file, if you
want to avoid cluttering up the logs.

Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2006-06-20 13:42:01 Re: shall we have a TRACE_MEMORY mode
Previous Message Alvaro Herrera 2006-06-20 13:05:07 Re: PAM auth