public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libgcc/109685] New: Memory leak in `__deregister_frame`
@ 2023-05-01 13:42 markus.boeck02 at gmail dot com
  2023-05-02  6:29 ` [Bug libgcc/109685] [13/14 Regression] " rguenth at gcc dot gnu.org
                   ` (8 more replies)
  0 siblings, 9 replies; 10+ messages in thread
From: markus.boeck02 at gmail dot com @ 2023-05-01 13:42 UTC (permalink / raw)
  To: gcc-bugs

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

            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 essentially
requires a JIT or extracts of binary sections I am not yet familiar with. If 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 suddenly
started getting memory leaks reports by the leak sanitizer within a JIT
application of mine using `__register_frame` and `__deregister_frame`, pointing
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/12de8da8961d294904d6af90b9cc27a5ba1ccfd0/libgcc/unwind-dw2-fde.c#L507
```
if ((accu->linear = malloc (size)))
    {
      accu->linear->count = 0;
      if ((accu->aux = malloc (size)))
        accu->aux->count = 0;
      return 1;
    }
```

Specifically the assignment to `accu->linear`. `accu->aux` is only temporarily
working memory that gets properly freed later. 
`accu->linear` instead gets put into an `object` that is inserted into a global
btree
(pointer is assigned to `u.sort`
https://github.com/gcc-mirror/gcc/blob/12de8da8961d294904d6af90b9cc27a5ba1ccfd0/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 = btree_remove (&registered_frames, range[0]);
#else
  ...
#endif

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

with the caller calling `free` on the returned `ob`. 
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 within
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. 
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

^ permalink raw reply	[flat|nested] 10+ messages in thread
end of thread, other threads:[~2023-09-28  9:02 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-05-01 13:42 [Bug libgcc/109685] New: Memory leak in `__deregister_frame` markus.boeck02 at gmail dot com
2023-05-02  6:29 ` [Bug libgcc/109685] [13/14 Regression] " rguenth at gcc dot gnu.org
2023-05-02 14:15 ` tneumann at users dot sourceforge.net
2023-05-02 14:16 ` tneumann at users dot sourceforge.net
2023-06-03  7:47 ` cvs-commit at gcc dot gnu.org
2023-06-03  7:57 ` cvs-commit at gcc dot gnu.org
2023-07-27  9:26 ` rguenth at gcc dot gnu.org
2023-07-27  9:28 ` tneumann at users dot sourceforge.net
2023-09-27 19:53 ` markus.boeck02 at gmail dot com
2023-09-28  9:02 ` redi at gcc dot gnu.org

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).