On Thu, Sep 16, 2021 at 01:55:22AM -0700, Carlo Marcelo Arenas Belón wrote: > b8ba412bf7 (tree-diff: avoid alloca for large allocations, 2016-06-07) > adds a way to route some bigger allocations out of the stack and free > them through the addition of two conveniently named macros, but leaves > the calls to free the xalloca part, which could be also in the heap, > if the system doesn't HAVE_ALLOCA_H (ex: macOS and other BSD). > > Add the missing free call, xalloca_free(), which is a noop if we > allocated memory in the stack frame, but a real free() if we > allocated in the heap instead, and while at it, change the expression > to match in both macros for ease of readability. Thanks, this is definitely my bug introduced by b8ba412bf7 and this is the right fix. I continue to find the whole xalloca() thing pretty gross, and doubly so now that there are _two_ layers of "maybe alloca(), and maybe malloc()" logic (one in xalloca(), and one in this FAST_ARRAY stuff). We should definitely take this fix to address the immediate problem, but I wonder if this size logic should be pushed into xalloca to make this kind of problem harder. Of course this is the only caller, so it might not matter much either way. (I'd also be really happy to see it go away entirely, as alloca() is a foot-gun in the first place. But I think it did make things slightly faster. It might be worth re-measuring). -Peff
