From: "Liang, Kan" <kan.liang@linux.intel.com>
To: Ian Rogers <irogers@google.com>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Namhyung Kim <namhyung@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Jiri Olsa <jolsa@kernel.org>,
Adrian Hunter <adrian.hunter@intel.com>,
Sun Haiyong <sunhaiyong@loongson.cn>,
Yanteng Si <siyanteng@loongson.cn>,
linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1] perf hist: Fix reference counting of branch_info
Date: Wed, 7 Aug 2024 09:27:02 -0400 [thread overview]
Message-ID: <277a02a5-9355-4f06-9158-026cf4b330f7@linux.intel.com> (raw)
In-Reply-To: <20240807065136.1039977-1-irogers@google.com>
On 2024-08-07 2:51 a.m., Ian Rogers wrote:
> iter_finish_branch_entry doesn't put the branch_info from/to map
> elements creating memory leaks. This can be seen with:
>
> ```
> $ perf record -e cycles -b perf test -w noploop
> $ perf report -D
> ...
> Direct leak of 984344 byte(s) in 123043 object(s) allocated from:
> #0 0x7fb2654f3bd7 in malloc libsanitizer/asan/asan_malloc_linux.cpp:69
> #1 0x564d3400d10b in map__get util/map.h:186
> #2 0x564d3400d10b in ip__resolve_ams util/machine.c:1981
> #3 0x564d34014d81 in sample__resolve_bstack util/machine.c:2151
> #4 0x564d34094790 in iter_prepare_branch_entry util/hist.c:898
> #5 0x564d34098fa4 in hist_entry_iter__add util/hist.c:1238
> #6 0x564d33d1f0c7 in process_sample_event tools/perf/builtin-report.c:334
> #7 0x564d34031eb7 in perf_session__deliver_event util/session.c:1655
> #8 0x564d3403ba52 in do_flush util/ordered-events.c:245
> #9 0x564d3403ba52 in __ordered_events__flush util/ordered-events.c:324
> #10 0x564d3402d32e in perf_session__process_user_event util/session.c:1708
> #11 0x564d34032480 in perf_session__process_event util/session.c:1877
> #12 0x564d340336ad in reader__read_event util/session.c:2399
> #13 0x564d34033fdc in reader__process_events util/session.c:2448
> #14 0x564d34033fdc in __perf_session__process_events util/session.c:2495
> #15 0x564d34033fdc in perf_session__process_events util/session.c:2661
> #16 0x564d33d27113 in __cmd_report tools/perf/builtin-report.c:1065
> #17 0x564d33d27113 in cmd_report tools/perf/builtin-report.c:1805
> #18 0x564d33e0ccb7 in run_builtin tools/perf/perf.c:350
> #19 0x564d33e0d45e in handle_internal_command tools/perf/perf.c:403
> #20 0x564d33cdd827 in run_argv tools/perf/perf.c:447
> #21 0x564d33cdd827 in main tools/perf/perf.c:561
> ...
> ```
>
> Clearing up the map_symbols properly creates maps reference count
> issues so resolve those. Resolving this issue doesn't improve peak
> heap consumption for the test above.
>
> Signed-off-by: Ian Rogers <irogers@google.com>
Reviewed-by: Kan Liang <kan.liang@linux.intel.com>
Thanks,
Kan
> ---
> tools/perf/util/hist.c | 18 ++++++++++++++----
> 1 file changed, 14 insertions(+), 4 deletions(-)
>
> diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c
> index f8ee1cd6929d..c8c1b511f8a7 100644
> --- a/tools/perf/util/hist.c
> +++ b/tools/perf/util/hist.c
> @@ -472,7 +472,9 @@ static int hist_entry__init(struct hist_entry *he,
> memcpy(he->branch_info, template->branch_info,
> sizeof(*he->branch_info));
>
> + he->branch_info->from.ms.maps = maps__get(he->branch_info->from.ms.maps);
> he->branch_info->from.ms.map = map__get(he->branch_info->from.ms.map);
> + he->branch_info->to.ms.maps = maps__get(he->branch_info->to.ms.maps);
> he->branch_info->to.ms.map = map__get(he->branch_info->to.ms.map);
> }
>
> @@ -970,10 +972,21 @@ iter_add_next_branch_entry(struct hist_entry_iter *iter, struct addr_location *a
> return err;
> }
>
> +static void branch_info__exit(struct branch_info *bi)
> +{
> + map_symbol__exit(&bi->from.ms);
> + map_symbol__exit(&bi->to.ms);
> + zfree_srcline(&bi->srcline_from);
> + zfree_srcline(&bi->srcline_to);
> +}
> +
> static int
> iter_finish_branch_entry(struct hist_entry_iter *iter,
> struct addr_location *al __maybe_unused)
> {
> + for (int i = 0; i < iter->total; i++)
> + branch_info__exit(&iter->bi[i]);
> +
> zfree(&iter->bi);
> iter->he = NULL;
>
> @@ -1319,10 +1332,7 @@ void hist_entry__delete(struct hist_entry *he)
> map_symbol__exit(&he->ms);
>
> if (he->branch_info) {
> - map_symbol__exit(&he->branch_info->from.ms);
> - map_symbol__exit(&he->branch_info->to.ms);
> - zfree_srcline(&he->branch_info->srcline_from);
> - zfree_srcline(&he->branch_info->srcline_to);
> + branch_info__exit(he->branch_info);
> zfree(&he->branch_info);
> }
>
next prev parent reply other threads:[~2024-08-07 13:27 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-07 6:51 [PATCH v1] perf hist: Fix reference counting of branch_info Ian Rogers
2024-08-07 13:27 ` Liang, Kan [this message]
2024-08-07 15:07 ` Arnaldo Carvalho de Melo
2024-08-07 15:42 ` Ian Rogers
2024-08-07 16:03 ` Ian Rogers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=277a02a5-9355-4f06-9158-026cf4b330f7@linux.intel.com \
--to=kan.liang@linux.intel.com \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=irogers@google.com \
--cc=jolsa@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
--cc=siyanteng@loongson.cn \
--cc=sunhaiyong@loongson.cn \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox