Re: Memory leaks - Mailing list pgsql-hackers

On Tue, 2002-10-22 at 17:09, Tom Lane wrote:
> Greg Copeland <greg@CopelandConsulting.Net> writes:
> > I've started playing a little with Postgres to determine if there were
> > memory leaks running around.  After some very brief checking, I'm
> > starting[1] to think that the answer is yes.  Has anyone already gone
> > through a significant effort to locate and eradicate memory leaks?
> 
> Yes, this has been dealt with before.

What tools, aside from noggin v1.0, did they use?  Do we know?

> Have you read
> src/backend/utils/mmgr/README?

Yes...but it's been some time since I last opened it.  It was because I
knew there were some caveats that I wasn't attempting to claim for sure
that there were leaks.

I then moved on to psql, again, just for fun.  Here, I'm thinking that I
started to find some other leaks...but again, I've not spent any real
time on it.  So again, I'm not really sure it they are meaningful at
this point.


> 
> AFAIK the major problems these days are not in the backend as a whole,
> but in the lesser-used PL language modules (cf recent discussions).

Ya, that's what made me wonder about the topic on a larger scale.

> plpgsql has some issues too, I suspect, but not as bad as pltcl etc.
> Possibly the best answer is to integrate the memory-context notion into
> those modules; if they did most of their work in a temp context that
> could be freed once per PL statement or so, the problems would pretty
> much go away.

Interesting.  Having not looked at memory management schemes used in the
pl implementations, can you enlighten me by what you mean by "integrate
the memory-context notion"?  Does that mean they are not using
palloc/pfree stuff?

> 
> It's fairly difficult to get anywhere with standard leak-tracking tools,
> since they don't know anything about palloc.  What's worse, it is *not*
> a bug for a routine to palloc space it never pfrees, if it knows that
> it's palloc'ing in a short-lived memory context.  The fact that a
> context may be released with much still-allocated memory in it is not a
> bug but a feature; but try teaching that to any standard leak checker...
> 
>             regards, tom lane

Well, the thing that really got my attention is that dmalloc is
reporting frees on null pointers.  While that may be safe on specific
platforms, IIRC, it's actually undefined.  Again, this is as reported by
dmalloc so I've yet to actually track it down to determine if it's
possibly something else going on (magic voodoo of some heap manager,
etc).


Greg