From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id A745C3858D32; Mon,  3 Oct 2022 12:25:46 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A745C3858D32
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1664799946;
	bh=WgrBJHnYAlG/gsJJIvwGys8M2CrPkKXuD1O6d3Cw1j0=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=EGR6RckMbouJ3McwwM876AWHKb31u9YC/dRH7GcDcrKCKTcXfhLPB615hCVWzwZ5o
	 +YzjeQ+IfuQsu0ZyPlQfC9C3B7Y6PZBxc5jMO+DJV2ebHOjaf6ymgi86MFj0+5w4tc
	 0cp5oBMLNQKUu4+0vsQ0Ggim2GXPMeYmuKdF1UR4=
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
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libgcc
X-Bugzilla-Version: 11.2.0
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: iam at datacompboy dot ru
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: attachments.created
Message-ID: <bug-106949-4-PhxMIXEo6v@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-106949-4@http.gcc.gnu.org/bugzilla/>
References: <bug-106949-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
List-Id: <gcc-bugs.sourceware.org>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D106949

--- Comment #2 from Anton Fedorov <iam at datacompboy dot ru> ---
Created attachment 53654
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=3D53654&action=3Dedit
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 does=
n'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 mat=
ter
when we enter the some large function that keeps calling the subfunction wi=
th
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 th=
at
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 =3D 0; i < s; i++) {
    n[i] =3D 0;
  }
  return -1;
}
int main() {
  int a =3D leak(1); a +=3D a;
  for(int i =3D 0; i < 10000; ++i)
    a +=3D 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 ex=
tra
cost for avoiding memory leak should be fine?=