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 011ED385843A; Mon,  1 May 2023 13:42:58 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 011ED385843A
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1682948578;
	bh=d/0FS7oVN/lTMKgRLSK9zWdZ7QeQGcITbGobTNlQp+w=;
	h=From:To:Subject:Date:From;
	b=b0kJ7SaytHBUKn6Y9P7JyNOFZibMyThZBu9sZbntV+jvaYtNX4NHlzjQI+1VfCAAt
	 IfcugqSLsDIDSKN3Ax6dLYZFRzOHCOXBlns3O/ryipIAVv1dHmBMqqeMKJFI0j2M+5
	 F+PeWP9ZP08N28IkupVrCASIYKLsZ69HIyi8nBKI=
From: "markus.boeck02 at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libgcc/109685] New: Memory leak in `__deregister_frame`
Date: Mon, 01 May 2023 13:42:56 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libgcc
X-Bugzilla-Version: 13.1.1
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: markus.boeck02 at gmail dot com
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
Message-ID: <bug-109685-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=3D109685

            Bug ID: 109685
           Summary: Memory leak in `__deregister_frame`
           Product: gcc
           Version: 13.1.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libgcc
          Assignee: unassigned at gcc dot gnu.org
          Reporter: markus.boeck02 at gmail dot com
  Target Milestone: ---

Sorry that I can't ship a proper reproducer, since I believe this essential=
ly
requires a JIT or extracts of binary sections I am not yet familiar with. I=
f I
do figure out a viable minimal reproducer I'll post them later.

With the recent release of GCC 13 landing on my fedora machine I have sudde=
nly
started getting memory leaks reports by the leak sanitizer within a JIT
application of mine using `__register_frame` and `__deregister_frame`, poin=
ting
to memory allocated by libgcc. I have then gone through debugging sessions =
with
GDB and found following oddities which I believe should be the causes of the
leak:

First of all, the memory allocation being leaked happens in `start_fde_sort`
https://github.com/gcc-mirror/gcc/blob/12de8da8961d294904d6af90b9cc27a5ba1c=
cfd0/libgcc/unwind-dw2-fde.c#L507
```
if ((accu->linear =3D malloc (size)))
    {
      accu->linear->count =3D 0;
      if ((accu->aux =3D malloc (size)))
        accu->aux->count =3D 0;
      return 1;
    }
```

Specifically the assignment to `accu->linear`. `accu->aux` is only temporar=
ily
working memory that gets properly freed later.=20
`accu->linear` instead gets put into an `object` that is inserted into a gl=
obal
btree
(pointer is assigned to `u.sort`
https://github.com/gcc-mirror/gcc/blob/12de8da8961d294904d6af90b9cc27a5ba1c=
cfd0/libgcc/unwind-dw2-fde.c#L918)

The above call chains happens the first time unwinding happens since objects
are lazily initialized.

Later during JIT shutdown, `__deregsiter_frame` is called to erase all the
unwind information that has been produced.

This leads us to following code:
```
#ifdef ATOMIC_FDE_FAST_PATH
  ...
  uintptr_type range[2];
  get_pc_range (&lookupob, range);

  // And remove
  ob =3D btree_remove (&registered_frames, range[0]);
#else
  ...
#endif

  gcc_assert (in_shutdown || ob);
  return (void *) ob;
```
https://github.com/gcc-mirror/gcc/blob/12de8da8961d294904d6af90b9cc27a5ba1c=
cfd0/libgcc/unwind-dw2-fde.c#L242

with the caller calling `free` on the returned `ob`.=20
Problem is that the `ob` may still have the pointer previously set by
`init_object` within its `u.sort` field. No attempt to free it is done with=
in
the `ATOMIC_FDE_FAST_PATH` region however (something that does happen in the
#else region, which is seemingly not the default or maybe not enabled by the
distribution).

This therefore leads to the memory pointed to by `ob->u.sort` to become
unreachable and leak.=20
The `ATOMIC_FDE_FAST_PATH` fast path was only added after the GCC 12 release
which would also explain why the LSAN only caught the leak after the GCC 13
release=