Re: shall we have a TRACE_MEMORY mode

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

In response to

Browse pgsql-hackers by date

  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