As I follow Relyea Mike's recent post of possible memory leak, I think that
we are lack of a good way of identifing memory usage. Maybe we should also
remember __FILE__, __LINE__ etc for better memory usage diagnose when
TRACE_MEMORY is on?
I find __FILE__ and __LINE__ very helpful
On 6/20/06, Tom Lane [EMAIL PROTECTED] wrote:
One idea that comes to mind is to have a compile time option to record
the palloc __FILE__ and _LINE__ in every AllocChunk header. Then it
would not be so hard to identify the culprit while trawling through
memory. The overhead costs would be so
On Tue, 2006-06-20 at 00:18 -0400, Tom Lane wrote:
One idea that comes to mind is to have a compile time option to record
the palloc __FILE__ and _LINE__ in every AllocChunk header. Then it
would not be so hard to identify the culprit while trawling through
memory. The overhead costs would
Simon Riggs wrote:
On Tue, 2006-06-20 at 00:18 -0400, Tom Lane wrote:
One idea that comes to mind is to have a compile time option to record
the palloc __FILE__ and _LINE__ in every AllocChunk header. Then it
would not be so hard to identify the culprit while trawling through
memory.
Alvaro Herrera said:
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
Andrew Dunstan wrote:
Alvaro Herrera said:
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
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
Tom Lane [EMAIL PROTECTED] writes:
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
Alvaro Herrera [EMAIL PROTECTED] 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.
Alvaro Herrera [EMAIL PROTECTED] 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
As I follow Relyea Mike's recent post of possible memory leak, I think that
we are lack of a good way of identifing memory usage. Maybe we should also
remember __FILE__, __LINE__ etc for better memory usage diagnose when
TRACE_MEMORY is on?
Regards,
Qingqing
---(end of
Qingqing Zhou wrote:
As I follow Relyea Mike's recent post of possible memory leak, I think that
we are lack of a good way of identifing memory usage. Maybe we should also
remember __FILE__, __LINE__ etc for better memory usage diagnose when
TRACE_MEMORY is on?
Hmm, this would have been a
Alvaro Herrera [EMAIL PROTECTED] writes:
About the exact form we'd give the feature: maybe write each
allocation/freeing to a per-backend file, say /tmp/pgmem.pid. Also
memory context creation, destruction, reset. Having the __FILE__ and
__LINE__ on each operation would be a good tracing
13 matches
Mail list logo