https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106949
--- Comment #2 from Anton Fedorov <iam at datacompboy dot ru> --- Created attachment 53654 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53654&action=edit potential fix I checked with the HEAD (43faf3e5445b571731e52faa1be085ecd0a09323) and the issue is still there. While it's kind of trivial to move the leak from "leak" to "not freed by the end of the program" with proposed patch to create an empty segment, it doesn't seems to fix the problem with the approach that there is no way to mark malloc()'ed alloca()'s in case we are on the main stack segment. But the problem extends beyond the allocation on the main segment -- no matter when we enter the some large function that keeps calling the subfunction with VLA/alloca, the memory will keep growing without collection. For example, if we'll call leak function in a loop (imagine we run even processing loop, network processing loop etc etc that calls some handler that have alloca/VLA), the memory will grow without any way to free it. ``` static int leak(int s) { volatile int n[5000+s]; for (int i = 0; i < s; i++) { n[i] = 0; } return -1; } int main() { int a = leak(1); a += a; for(int i = 0; i < 10000; ++i) a += leak(i+1); return 0; } ``` I see the option to generate code to explicitly move N (number of calls to __morestack_allocate_stack_space in the function) first dynamic_allocation elements to free_dynamic_allocation list before execution return -- at cost of extra check & jmp for case when stack is sufficient. Given that -fsplit-stack accepts extra cost for stack guarantees -- this extra cost for avoiding memory leak should be fine?
