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
Views: Raw Message | Whole Thread | Download mbox
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

Browse pgsql-hackers by date

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

Browse pgsql-bugs by date

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