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 B27CE385841F; Tue,  4 Oct 2022 12:16:21 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B27CE385841F
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1664885781;
	bh=Zv6LsdjFxGodO70uZxiuZ4DgA7LXM0e9bKQCP4OSZKI=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=UZbnyeJYts3j7J4zcQHQb30p8D8pw9dZHDIDDZ2u0cvFJM9X4Dc8TOiLU3cunVQhw
	 YI4NaBAwgTP5wWQg1tm5zZr0MmaSkyydA5E7Z1cUllaSq6ywd+zLOyLTXDXPpidOFe
	 SiShma6BKo8v/X3I6irTPjm3kAhO/e57hfq0xCgI=
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/alloca with -fsplit-stack
Date: Tue, 04 Oct 2022 12:16:20 +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: 13.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: 
Message-ID: <bug-106949-4-lA3eaWZeq7@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 #4 from Anton Fedorov <iam at datacompboy dot ru> ---
> You can't just add a stack segment without changing the stack pointer.

I can -- since we are on the initial stack at this point, no return into
__morestack will happen so no attempt to release it, thus there is no probl=
em
and it won't affect subsequent allocations of frames would it be necessary.

But that's the catch: the allocated blocks won't be released no matter is w=
e on
the initial stack or deep inside, until we try to release the frame, which =
may
never happen no matter are we on the initial stack or not.

the easiest way may be change gcc generate the code like:

```
struct __morestack_blocks {
  struct __morestack_blocks * next;
  void * block;
};

void __morestack_free_blocks(struct __morestack_blocks ** blocks) {
  struct __morestack_blocks * cur =3D *blocks;
  while(cur) {
    free(cur->block);
    cur =3D cur->next;
  }
}

void* __morestack_allocate_stack_space(int size, struct __morestack_blocks =
**
blocks){ ... }

somefunction(someargs) {
  struct __morestack_blocks __attribute__((cleanup(__morestack_free_blocks)=
)) =3D
nullptr;

  // void * a =3D alloca(x);
  a =3D __morestack_allocate_stack_space(x, &__morestack_blocks);

}
```

But that local variable to be used as a reference, but makes it trivial
(although, I don't know how to generate local variable with assigned destru=
ctor
from the gcc code, will look for it)...=