Re: [CHECKER] 4 memory leaks in Postgresql 7.4.2

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
>