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 D12773858D37; Mon, 15 Jan 2024 16:35:50 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D12773858D37
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1705336550;
	bh=Pnwznp7C3k/Xf+1APbnh4Uhosl2EZwWWZcdHsMJud3E=;
	h=From:To:Subject:Date:From;
	b=nl0fvNkyER0A6bNOiHGtVKEkWhL6R1gQIwBvRyGtW6G+9eL5r2hRCBoz9bLDSLMzK
	 uxSr0QBLjRNE62kly7LsXFPmVV4CYF3afWVpqT0fZkpVQ4DW0WWcpG2YYd7XJoKSds
	 y605ouVWO2WXgqfoyq5RqDkEbFj0VtUzzhOMl0uY=
From: "fw at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/113401] New: Memory (resource) leak in
 -ftrampoline-impl=heap
Date: Mon, 15 Jan 2024 16:35:50 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: fw at gcc dot gnu.org
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: bug_id short_desc product version bug_status
 bug_severity priority component assigned_to reporter target_milestone
 cf_gcctarget
Message-ID: <bug-113401-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=3D113401

            Bug ID: 113401
           Summary: Memory (resource) leak in -ftrampoline-impl=3Dheap
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: fw at gcc dot gnu.org
  Target Milestone: ---
            Target: x86_64-*, aarch64-*

Consider this test program:

#include <err.h>
#include <errno.h>
#include <pthread.h>

static void *volatile compiler_barrier;

void *
thread_routine (void *ignore)
{
  int local_variable;
  auto int *local_function (void)
  {
    return &local_variable;
  }
  compiler_barrier =3D local_function;
  return NULL;
}

int
main (void)
{
  for (int i =3D 0; i < 10000; ++i)
    {
      pthread_t thread;
      int ret =3D pthread_create (&thread, NULL, thread_routine, NULL);
      if (ret !=3D 0)
        {
          errno =3D ret;
          err (1, "pthread_create");
        }
      ret =3D pthread_join (thread, NULL);
      if (ret !=3D 0)
        {
          errno =3D ret;
          err (1, "pthread_join");
        }
    }
}

With -ftrampoline-impl=3Dstack, I get:

$ \time ./a.out=20
0.01user 0.16system 0:00.18elapsed 102%CPU (0avgtext+0avgdata 3008maxreside=
nt)k
0inputs+0outputs (0major+68minor)pagefaults 0swaps

With -ftrampoline-impl=3Dheap:

$ \time ./a.out=20
0.03user 0.17system 0:00.20elapsed 101%CPU (0avgtext+0avgdata
41796maxresident)k
0inputs+0outputs (0major+10148minor)pagefaults 0swaps

The reason for the maxresident change is that __builtin_nested_func_ptr_cre=
ated
and __builtin_nested_func_ptr_deleted cache the last trampoline page even i=
f it
is completely unused. This is required for performance reasons. The fix is =
to
register a TLS destructor to deallocate that page, too. On glibc, that also
fixes another memory leak for -fno-exceptions compilations (the default for=
 C)
if pthread_exit is called with an active trampoline.=