Skip site navigation (1) Skip section navigation (2)

Re: [CHECKER] 4 memory leaks in Postgresql 7.4.2

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Neil Conway <neilc(at)samurai(dot)com>
Cc: Ted Kremenek <kremenek(at)cs(dot)stanford(dot)edu>,pgsql-bugs(at)postgresql(dot)org, Michael Meskes <meskes(at)postgresql(dot)org>
Subject: Re: [CHECKER] 4 memory leaks in Postgresql 7.4.2
Date: 2004-05-02 23:50:46
Message-ID: 2896.1083541846@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-bugspgsql-hackers
Neil Conway <neilc(at)samurai(dot)com> writes:
> The problem with applying this kind of static analysis to PostgreSQL is 
> that palloc() is not like malloc(): if the return value goes out of 
> scope before it is freed, it is NOT necessarily the case that a memory 
> leak has occurred.

I'm a bit surprised that a tool unaware of this fact would generate only
four complaints ... I'd have expected hundreds.

I concur with Neil's opinion that none of the backend cases represent
bugs.  However:

>> [BUG] memory leak on error path (dtype != DTK_DELTA)
>> File where bug occurred: 
>> postgresql-7.4.2/src/interfaces/ecpg/pgtypeslib/interval.c

> Looks suspicious to me, but ECPG is Michael Meskes' domain -- Michael?

It's entirely likely that ecpg's derivative of the backend's datetime
modules contains lots and lots of memory leaks, since AFAIK the palloc
infrastructure is not there in the ecpg environment :-(.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Peter EisentrautDate: 2004-05-02 23:51:15
Subject: Re: Fixed directory locations in installs
Previous:From: Alvaro HerreraDate: 2004-05-02 23:15:43
Subject: Re: SET WITHOUT CLUSTER patch

pgsql-bugs by date

Next:From: Ted KremenekDate: 2004-05-03 03:22:07
Subject: Re: [CHECKER] 4 memory leaks in Postgresql 7.4.2
Previous:From: Ted KremenekDate: 2004-05-02 20:45:35
Subject: Re: [CHECKER] 4 memory leaks in Postgresql 7.4.2

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group