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 | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-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
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 |
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 |