> On Oct 19, 2026, at 14:51, David Rowley <[email protected]> wrote:
>
> On Mon, 19 Oct 2026 at 19:04, Chao Li <[email protected]> wrote:
>>>> In summary, this bug doesn’t lead to memory leaks, but it breaks
>>>> AllocSet’s intended allocation behavior: sometimes causing unexpected
>>>> malloc()/free() calls, and sometimes unexpected pooling and memory
>>>> retention.
>>> Per the comment you moved to the helper function, if allocChunkLimit
>>> doesn't follow the ALLOC_CHUNK_FRACTION formula, it could also lead to
>>> unexpected size of memory waste at a block's tail.
>>
>> Yes, that’s another consequence of stale larger allocChunkLimit.
>
> I don't think this is 100% accurate, as when a non-large allocation is
> made and there's not enough remaining space in the block, the
> remaining space is divvied up and put onto the freelists. That might
> happen to get wasted of those freelist items are never used, but to
> say the entire remaining space is wasted isn't strictly true.
Thanks for the clarification.
>
> I did consider if this was worth a backpatch and I think it is, as
> having the performance characteristics depend on the random chance of
> what context was last pushed onto the freelist doesn't seem great.
>
> I've backpatched this to v14. I kept the comments prior to the
> allocChunkLimit being set the same as they had been in each version.
> Annoyingly, that block had changed various times since v14.
Thanks for pushing and back-patching.
>
> I took the liberty and added an Assert(set->nextBlockSize ==
> set->initBlockSize); to clarify that we expect that to have been done
> the last time the context was reset.
>
> David
Sounds good.
BTW, I learned to use "make check" for this kind of testing from you, so thanks
again.
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/
