Re: [HACKERS] Everything leaks; How it mm suppose to work? - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: [HACKERS] Everything leaks; How it mm suppose to work?
Date
Msg-id 199804021558.KAA15251@candle.pha.pa.us
Whole thread Raw
In response to Everything leaks; How it mm suppose to work?  (Maurice Gittens <mgittens@david.gits.nl>)
List 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)

pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] Open 6.3.1 issues
Next
From: "Maurice Gittens"
Date:
Subject: Re: [HACKERS] Everything leaks; How it mm suppose to work?