Re: [PATCH perf/core 00/13] perf memory/refcnt leak fixes

From: Arnaldo Carvalho de Melo
Date: Wed Nov 18 2015 - 07:46:56 EST


Em Wed, Nov 18, 2015 at 03:40:09PM +0900, Masami Hiramatsu escreveu:
> Hi,
>
> Here is a series to fix some memory leaks and refcount
> leaks on map and dso. This also includes the refcnt APIs
> with backtrace debugging feature.

Cool, I wonder if this could be usable in the kernel proper... Is there
such a facility there? I'll check.

But thanks for doing this work, I'll go thru the fixes first, then look
at the debugging feature.

- Arnaldo

> The story has started from the posible memory leak report
> reported by Wnag Nan.
> I've tried to use valgrind to ensure the perf probe doesn't
> have other memory leaks. The result is here:
>
> ----
> # valgrind ./perf probe vfs_read
> ==17521== Memcheck, a memory error detector
> ==17521== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
> ==17521== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
> ==17521== Command: ./perf probe vfs_read
> ==17521==
> Added new event:
> probe:vfs_read (on vfs_read)
>
> You can now use it in all perf tools, such as:
>
> perf record -e probe:vfs_read -aR sleep 1
>
> ==17521==
> ==17521== HEAP SUMMARY:
> ==17521== in use at exit: 3,512,761 bytes in 38,012 blocks
> ==17521== total heap usage: 74,723 allocs, 36,711 frees, 24,014,927
> bytes allocated
> ==17521==
> ==17521== LEAK SUMMARY:
> ==17521== definitely lost: 6,857 bytes in 49 blocks
> ==17521== indirectly lost: 3,501,287 bytes in 37,891 blocks
> ==17521== possibly lost: 0 bytes in 0 blocks
> ==17521== still reachable: 4,617 bytes in 72 blocks
> ==17521== suppressed: 0 bytes in 0 blocks
> ==17521== Rerun with --leak-check=full to see details of leaked memory
> ==17521==
> ==17521== For counts of detected and suppressed errors, rerun with: -v
> ==17521== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2)
> ----
>
> Oops! It leaked almost 4 MB memories. I've tried to find
> the root causes, and what I've found is there are many
> leaks in not only perf-probe specific code, but also maps
> and dsos (and some other pieces).
>
> The first 3 patches are just fixing 'easy' memory leaks. However,
> most of the leaks are caused by refcnt. Since valgrind seems not
> able to debug this kind of issues, I introduced a hand-made refcnt
> backtrace APIs for debugging.
> The rest of patches are for fixing refcnt leak bugs and replcing
> refcnt apis.
>
> After all, most of the issues are gone, except for just a few issues
> in elfutils. I'll continue to investigate that.
>
> ----
> valgrind ./perf probe vfs_read
> ==29521== Memcheck, a memory error detector
> ==29521== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
> ==29521== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
> ==29521== Command: ./perf probe vfs_read
> ==29521==
> Added new event:
> probe:vfs_read (on vfs_read)
>
> You can now use it in all perf tools, such as:
>
> perf record -e probe:vfs_read -aR sleep 1
>
> ==29521==
> ==29521== HEAP SUMMARY:
> ==29521== in use at exit: 5,137 bytes in 75 blocks
> ==29521== total heap usage: 74,723 allocs, 74,648 frees, 24,014,927
> bytes allocated
> ==29521==
> ==29521== LEAK SUMMARY:
> ==29521== definitely lost: 520 bytes in 3 blocks
> ==29521== indirectly lost: 0 bytes in 0 blocks
> ==29521== possibly lost: 0 bytes in 0 blocks
> ==29521== still reachable: 4,617 bytes in 72 blocks
> ==29521== suppressed: 0 bytes in 0 blocks
> ==29521== Rerun with --leak-check=full to see details of leaked memory
> ==29521==
> ==29521== For counts of detected and suppressed errors, rerun with: -v
> ==29521== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2)
> ----
>
> Anyway, I decided to release these fixes and the debugging feature
> because at least this will improve perf quality.
>
> Thank you,
>
> ---
>
> Masami Hiramatsu (13):
> perf probe: Fix to free temporal Dwarf_Frame
> perf: Make perf_exec_path always returns malloc'd string
> perf: Introduce generic refcount APIs with debug feature
> perf: make map to use refcnt
> perf: Fix machine__findnew_module_map to put registered map
> perf: Fix machine__destroy_kernel_maps to put vmlinux_maps
> perf: Fix to destroy kernel maps when machine exits
> perf: Fix to put new map after inserting to map_groups in dso__load_sym
> perf: Make dso to use refcnt for debug
> perf: Fix __dsos__addnew to put dso after adding it to the list
> perf: Fix machine__create_kernel_maps to put kernel dso
> perf: Fix machine__findnew_module_map to put dso
> perf: Fix dso__load_sym to put dso
>
>
> tools/perf/config/Makefile | 5 ++
> tools/perf/util/Build | 1
> tools/perf/util/dso.c | 9 ++-
> tools/perf/util/exec_cmd.c | 20 ++++--
> tools/perf/util/exec_cmd.h | 5 +-
> tools/perf/util/help.c | 6 +-
> tools/perf/util/machine.c | 17 ++++-
> tools/perf/util/map.c | 7 +-
> tools/perf/util/map.h | 3 +
> tools/perf/util/probe-finder.c | 9 ++-
> tools/perf/util/refcnt.c | 125 ++++++++++++++++++++++++++++++++++++++++
> tools/perf/util/refcnt.h | 65 +++++++++++++++++++++
> tools/perf/util/symbol-elf.c | 4 +
> 13 files changed, 250 insertions(+), 26 deletions(-)
> create mode 100644 tools/perf/util/refcnt.c
> create mode 100644 tools/perf/util/refcnt.h
>
>
> --
> Masami HIRAMATSU
> Linux Technology Research Center, System Productivity Research Dept.
> Center for Technology Innovation - Systems Engineering
> Hitachi, Ltd., Research & Development Group
> E-mail: masami.hiramatsu.pt@xxxxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/