From: | korry <korry(at)appx(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: shall we have a TRACE_MEMORY mode |
Date: | 2006-06-22 14:47:30 |
Message-ID: | 1150987650.7496.42.camel@sakai.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> > 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 when debugging both leaks and
corruption. I also add a per-context (AllocSetContext.callCount) "call
counter". Each time a new piece of memory is allocated from a context,
I bump the call counter and record the new value in the header for that
chunk of memory (AllocChunkData.callCount). That way, I can look at a
chunk of memory and know that it was allocated the 42nd time that I
grabbed a hunk of memory from that context. The next time I run my
test, I can set a conditional breakpoint (cond callCounter==42) that
stops at the correct allocation (and thus grab my stack dump). The
numbers aren't always exactly the same, but in most cases they are.
Obviously you're now writing 12 extra bytes of overhead to each
AllocChunkData (__FILE__, __LINE__, and callCount) and 4 bytes to each
AllocSetContext (callCount).
-- Korry
From | Date | Subject | |
---|---|---|---|
Next Message | Relyea, Mike | 2006-06-22 14:56:53 | Re: Out of memory error in 8.1.0 Win32 |
Previous Message | Mario Weilguni | 2006-06-22 14:44:04 | Re: vacuum, performance, and MVCC |