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

From Martijn van Oosterhout
Subject Re: shall we have a TRACE_MEMORY mode
Date
Msg-id 20060620131409.GA25678@svana.org
Whole thread Raw
In response to Re: shall we have a TRACE_MEMORY mode  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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@svana.org>   http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.

pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: PAM auth
Next
From: Tom Lane
Date:
Subject: Re: shall we have a TRACE_MEMORY mode