Re: Fix stale allocChunkLimit when recycling AllocSet

> On Oct 19, 2026, at 14:51, David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
>
> On Mon, 19 Oct 2026 at 19:04, Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> 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/