Re: [HACKERS] Everything leaks; How it mm suppose to work?

Bruce Momjian <maillist@candle.pha.pa.us>

From: Bruce Momjian <maillist@candle.pha.pa.us>
To: mgittens@david.gits.nl (Maurice Gittens)
Cc: hackers@postgreSQL.org
Date: 1998-04-02T15:58:08Z
Lists: pgsql-hackers
> 
> Hi,
> 
> I added these lines to tcop/postgres.c just before the ReadCommand call
> (which is in an infinite loop).
> 
> + 		printf("Allocount: %ld; FreeCount: %ld; Diff:%ld\n", 
> + 				getPAllocCount(),
> + 				getPFreeCount(),
> + 				getPAllocCount() - getPFreeCount());
> + 
> 
> And the following lines to mmgr/palloc.c
>   
> + static long pallocCount = 0;
> + static long pfreeCount = 0;
> + 
> + long getPAllocCount()
> + {
> + 	return pallocCount;
> + }
> + 
> + long getPFreeCount()
> + {
> + 	return pfreeCount;
> + }
> 
>   void *
>   palloc(Size size)
>   {
> + 	pallocCount++;
>    ...
> 
>   void
>   pfree(void *pointer)
>   {
> + 	pfreeCount++;
>         ...
> 
> Running postgresql in interactive mode shows that for each query I 
> type there is memory lost. The exact amount of memory lost depends on
> the query I use. The amount of memory not freed is also a function
> of the number of tuples returned.
> 
> Now I'm hoping there is an easy way to find out about how this is _supposed_ 
> to work. Any one feel like giving a nice little explanation?
> 
> Thanks, with regards from Maurice.

The way I was looking at it was to first find the context that is
loosing the memory.  I called AllocSetDump(GlobalMemory->setData) to
dump out the allocated memory pointers.  The problem is that only
certain ones are do-able, as portals each have their own context, I
think, and there is no macro that enables all the memory debugging
operations.

Not sure how to proceed.

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)