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

From Andres Freund
Subject Re: SlabCheck leaks memory into TopMemoryContext
Date
Msg-id 20200116064143.opcu2vhcktddpzbh@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  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Re: SlabCheck leaks memory into TopMemoryContext  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Hi,

On 2020-01-16 01:25:00 -0500, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > On 2020-01-16 00:09:53 -0500, Tom Lane wrote:
> >> 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.
> 
> In the AllocSet code, we don't hesitate to expend extra space per-chunk
> for debug support:
> 
> typedef struct AllocChunkData
> {
> ...
> #ifdef MEMORY_CONTEXT_CHECKING
>     Size        requested_size;
> #endif
> ...
> 
> I don't see a pressing reason why SlabContext couldn't do something
> similar, either per-chunk or per-context, whatever makes sense.

Well, what I suggested upthread, was to just have two globals like

int slabcheck_freechunks_size;
bool *slabcheck_freechunks;

and realloc that to the larger size in SlabContextCreate() if necessary,
based on the computed chunksPerBlock?  I thought you were asking whether
any additional memory could just be avoided...

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: SlabCheck leaks memory into TopMemoryContext
Next
From: Kyotaro Horiguchi
Date:
Subject: Re: Append with naive multiplexing of FDWs