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

Re: [CHECKER] 4 memory leaks in Postgresql 7.4.2

From: Ted Kremenek <kremenek(at)cs(dot)stanford(dot)edu>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-bugs(at)postgresql(dot)org,Michael Meskes <meskes(at)postgresql(dot)org>,Neil Conway <neilc(at)samurai(dot)com>
Subject: Re: [CHECKER] 4 memory leaks in Postgresql 7.4.2
Date: 2004-05-03 03:22:07
Message-ID: 0E9EB102-9CB1-11D8-BF2F-000393B3CE92@cs.stanford.edu (view raw or flat)
Thread:
Lists: pgsql-bugspgsql-hackers
Since the tool is in its nascent stages, I reported only a handful of 
reports that I myself looked at felt that they were potentially bugs.

I appreciate everyone's feedback.

Best,
Ted

On May 2, 2004, at 4:50 PM, Tom Lane wrote:

> 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
>
> ---------------------------(end of 
> broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
>                http://www.postgresql.org/docs/faqs/FAQ.html


In response to

pgsql-hackers by date

Next:From: Philip WarnerDate: 2004-05-03 03:35:18
Subject: Re: ANALYZE locks pg_listener in EXCLUSIVE for long
Previous:From: Bruce MomjianDate: 2004-05-03 03:13:04
Subject: Re: ANALYZE locks pg_listener in EXCLUSIVE for long time?

pgsql-bugs by date

Next:From: Timo NentwigDate: 2004-05-03 16:08:23
Subject: Bug in optimizer
Previous:From: Tom LaneDate: 2004-05-02 23:50:46
Subject: Re: [CHECKER] 4 memory leaks in Postgresql 7.4.2

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