Re: [CHECKER] 4 memory leaks in Postgresql 7.4.2

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