Re: SlabCheck leaks memory into TopMemoryContext - Mailing list pgsql-hackers

From Andres Freund
Subject Re: SlabCheck leaks memory into TopMemoryContext
Date
Msg-id 20200116061732.vvpyexenaortpu5y@alap3.anarazel.de
Whole thread Raw
In response to Re: SlabCheck leaks memory into TopMemoryContext  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: SlabCheck leaks memory into TopMemoryContext
List pgsql-hackers
Hi,

On 2020-01-16 00:09:53 -0500, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > I just noticed that having a slab context around in an assertion build
> > leads to performance degrading and memory usage going up. A bit of
> > poking revealed that SlabCheck() doesn't free the freechunks it
> > allocates.
>
> > It's on its own obviously trivial to fix.
>
> It seems like having a context check function do new allocations
> is something to be avoided in the first place.

Yea, that's why I was wondering about doing the allocation during
context creation, for the largest size necessary of any context:

    /* bitmap of free chunks on a block */
    freechunks = palloc(slab->chunksPerBlock * sizeof(bool));

or at the very least using malloc(), rather than another context.


> It's basically assuming that the memory management mechanism is sane,
> which makes the whole thing fundamentally circular, even if it's
> relying on some other context to be sane.  Is there a way to do the
> checking without extra allocations?

Probably not easily.

Was wondering if the bitmap could be made more dense, and allocated on
the stack. It could actually using one bit for each tracked chunk,
instead of one byte. Would have to put in a clear lower limit of the
allowed chunk size, in relation to the block size, however, to stay in a
reasonable range.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Kyotaro Horiguchi
Date:
Subject: Re: relcache sometimes initially ignores has_generated_stored
Next
From: Tom Lane
Date:
Subject: Re: SlabCheck leaks memory into TopMemoryContext