public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "iam at datacompboy dot ru" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug libgcc/106949] Memory leak using VLA with -fsplit-stack Date: Mon, 03 Oct 2022 12:25:46 +0000 [thread overview] Message-ID: <bug-106949-4-PhxMIXEo6v@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-106949-4@http.gcc.gnu.org/bugzilla/> 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?
next prev parent reply other threads:[~2022-10-03 12:25 UTC|newest] Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-09-15 8:18 [Bug libgcc/106949] New: " iam at datacompboy dot ru 2022-09-15 8:21 ` [Bug libgcc/106949] " iam at datacompboy dot ru 2022-10-03 12:25 ` iam at datacompboy dot ru [this message] 2022-10-04 0:22 ` ian at airs dot com 2022-10-04 12:16 ` [Bug libgcc/106949] Memory leak using VLA/alloca " iam at datacompboy dot ru 2022-10-04 15:50 ` iam at datacompboy dot ru
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-106949-4-PhxMIXEo6v@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).