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

> > >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.
> > >
> >
> > Oops, it seems some palloc'ed memory is not freed by pfree() but
> > using some other function(s).
> > My mistake, sorry.
>
> OK, I think I know where the leak is from.  I checked AllocSetDump(), and
> it did not show any problems with any context growing, so I started to
> suspect direct calls to malloc().  I tried trapping on malloc(), but
> there are too many calls.
>
> Then I ran profiling on the two queries I mentioned, where one leaks and
> one doesn't, and found that the leaking one had 500 extra calls to
> malloc.  Grep'ing out the calls and comparing the output of the two
> profiles, I found:
>
>                 0.00        0.00       1/527         ___irs_gen_acc [162]
>                 0.00        0.00      35/527         _GetDatabasePath [284]
>                 0.00        0.00     491/527         _GetDatabaseName [170]
> [166]    0.8    0.00        0.00     527         _strdup [166]
>                 0.00        0.00     527/2030        _malloc [105]
>                 0.00        0.00     527/604         _strlen [508]
>                 0.00        0.00     527/532         _bcopy [515]
>
>
> I believe this code was modified by Vadim to fix our problem with blind
> write errors when using psql while the regression tests were being run.
>
> Am I correct on this?  I have not developed a fix yet.

How about changing the strdup()'s in src/backend/utils/init/miscinit.c to
the pstrdup() that is in palloc.c so the memory is palloc()/pfree()'d?

I seem to recall a discussion a long time ago about using strdup and how
it would leak when using the postgres memory contexts, and that the pstrdup
code was created to be used instead of strdup to "fix" this.

darrenk