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: Neil Conway <neilc(at)samurai(dot)com>
Cc: Michael Meskes <meskes(at)postgresql(dot)org>, mc(at)cs(dot)Stanford(dot)EDU,pgsql-bugs(at)postgresql(dot)org
Subject: Re: [CHECKER] 4 memory leaks in Postgresql 7.4.2
Date: 2004-05-02 20:45:35
Message-ID: A92FA110-9C79-11D8-BF06-000393B3CE92@cs.stanford.edu (view raw, whole thread or download thread mbox)
Thread:
Lists: pgsql-bugspgsql-hackers
Thanks Neil.  The information about palloc() is extremely useful, and 
it will be interesting for us to see how our analysis can better deal 
with this.

Thanks for the quick reply!

Best,
Ted

On May 2, 2004, at 12:23 PM, Neil Conway wrote:

> On 2-May-04, at 2:05 PM, Ted Kremenek wrote:
>> I'm from the Stanford Metacompilation research group where we use 
>> static analysis to find bugs.
>
> Neat. BTW, I saw a talk last summer from Madanlal Musuvathi on some 
> model checking work which I believe is being done by a related group 
> at Stanford; it was very interesting.
>
> 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. Each palloc() allocation occurs within a "memory 
> context" (a.k.a an arena, if you're familiar with the usage in tcc). 
> Individual allocations can be released via pfree(), or the entire 
> memory context and all memory allocated within it can be released via 
> MemoryContextReset() or a similar function. Some areas of the code 
> bother doing a pfree() for each palloc(); some do not.
>
>> [BUG] memory leak of vacrelstats at end of function laxy_vaccum_rel()
>> File where bug occurred: 
>> postgresql-7.4.2/src/backend/commands/vacuumlazy.c
>
> I believe the CommitTransactionCommand() at vacuum.c:894 (which calls 
> CommitTransaction(), which calls AtCommit_Memory(), which performs a 
> MemoryContextDelete()) deallocates this memory reasonably soon after 
> it has been allocated, so this isn't a bug.
>
>> [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?
>
>> [BUG] difficult to analyze, but it appears that subquery is memory 
>> leaked
>> File where bug occurred: 
>> postgresql-7.4.2/src/backend/optimizer/plan/subselect.c
>
> Not sure about this one -- I didn't bother tracking down exactly where 
> the memory context manipulation happens, but I think it's likely that 
> we release this memory fairly soon after it's allocated.
>
>> [BUG] memory leak, pformats is allocated but never freed or stored 
>> anywhere
>
> Doesn't look like a bug to me: pformats is allocated in the 
> MessageContext (e.g. tcop/postgres.c:1308), which is reset for every 
> FE command that is processed (e.g. postgres.c:2849).
>
> -Neil
>


In response to

pgsql-hackers by date

Next:From: Peter EisentrautDate: 2004-05-02 21:05:54
Subject: Re: Fixed directory locations in installs
Previous:From: Magnus HaganderDate: 2004-05-02 20:38:32
Subject: Re: Fixed directory locations in installs

pgsql-bugs by date

Next:From: Tom LaneDate: 2004-05-02 23:50:46
Subject: Re: [CHECKER] 4 memory leaks in Postgresql 7.4.2
Previous:From: Neil ConwayDate: 2004-05-02 19:23:22
Subject: Re: [CHECKER] 4 memory leaks in Postgresql 7.4.2

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