Re: Memory leak from ExecutorState context?

On 3/1/23 19:09, Jehan-Guillaume de Rorthais wrote:
> On Wed, 1 Mar 2023 18:48:40 +0100
> Jehan-Guillaume de Rorthais <jgdr@dalibo.com> wrote:
> ...
>> You'll find some intermediate stats I already collected in attachment:
>>
>> * break 1, 2 and 3 are from AllocSetAlloc, break 4 is from AllocSetFree.
>> * most of the non-free'd chunk are allocated since the very beginning, before
>>   the 5000's allocation call for almost 1M call so far.
>> * 3754 of them have a chunk->size of 0
>> * it seems there's some buggy stats or data:
>>        # this one actually really comes from the gdb log
>>        0x38a77b8: break=3 num=191       sz=4711441762604810240 (weird sz)
>>        # this one might be a bug in my script
>>              0x2: break=2 num=945346    sz=2                   (weird address)
>> * ignoring the weird size requested during the 191st call, the total amount
>>   of non free'd memory is currently 5488MB
> 
> I forgot one stat. I don't know if this is expected, normal or not, but 53
> chunks has been allocated on an existing address that was not free'd before.
> 

It's likely chunk was freed by repalloc() and not by pfree() directly.
Or maybe the whole context got destroyed/reset, in which case we don't
free individual chunks. But that's unlikely for the ExecutorState.

regards

-- 
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company