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
---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings