All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Arnaldo Carvalho de Melo" <acme@kernel.org>
Cc: linux-perf-users@vger.kernel.org
Subject: Re: [PATCH v1 4/8] perf annotate-data: Show the sample count in the data-type browser
Date: Sun, 13 Sep 2026 02:43:32 +0000	[thread overview]
Message-ID: <20260913024333.17BB41F00893@smtp.kernel.org> (raw)
In-Reply-To: <20260913023459.112654-5-acme@kernel.org>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [High] This problem wasn't introduced by this patch, but child nodes and their 'hists' arrays are leaked during browser entries deletion.
- [Medium] This problem wasn't introduced by this patch, but there are missing POSIX libc header inclusions for `snprintf`, `calloc`, and `free`.
--

commit 5a4ac13ab552e8559bedbbcd49a2b0cf582b03bc
Author: Arnaldo Carvalho de Melo <acme@redhat.com>

perf annotate-data: Show the sample count in the data-type browser

The data-type browser has a samples view, selected with -n (or with
annotate.show_nr_samples), in which browser__write_overhead() prints a
local nr_samples variable that is initialized to zero and never
updated, so every member is listed as having no samples while the
period and percent columns for the same entry are filled in.

Print the histogram entry's own count instead.

This predates the load/store counter split, so fix it ahead of that
patch: the split then only has to adapt a line that is already correct,
and this fix can be picked on its own.

Fixes: d001c7a7f4736743 ("perf annotate-data: Add hist_entry__annotate_data_tui()")
Assisted-by: LLM
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>

> diff --git a/tools/perf/ui/browsers/annotate-data.c b/tools/perf/ui/browsers/annotate-data.c
> index aa8c89fe2e82c..1080ed1a40d26 100644
> --- a/tools/perf/ui/browsers/annotate-data.c
> +++ b/tools/perf/ui/browsers/annotate-data.c

[ ... ]

[Severity: High]
This isn't a bug introduced by this patch, but child nodes and their hists
arrays are leaked when browser entries are deleted:

tools/perf/ui/browsers/annotate-data.c:annotated_data_browser__delete_entries() {
	list_for_each_entry_safe(pos, tmp, &browser->entries, node) {
		list_del_init(&pos->node);
		zfree(&pos->hists);
		free(pos);
	}
}

The loop exclusively iterates over the top-level nodes in the browser->entries
list. Does this leak the memory for all nested child nodes in pos->children and
their associated hists arrays?

If a user repeatedly opens and closes the data type annotation TUI, could this
unbounded leak eventually exhaust system memory and crash the tool during a
long-lived interactive session?


[Severity: Medium]
This is a pre-existing issue, but does this file fail to build under musl libc?

tools/perf/ui/browsers/annotate-data.c
	#include <inttypes.h>
	#include <string.h>
	#include <linux/zalloc.h>
	#include <sys/ttydefaults.h>

The code uses functions from stdio.h (snprintf) and stdlib.h (calloc, free)
without explicitly including these headers. Could we add these missing POSIX
libc header inclusions to ensure musl compilation compatibility?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260913023459.112654-1-acme@kernel.org?part=4

  reply	other threads:[~2026-09-13  2:43 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-13  2:34 [PATCH v1 0/8] perf tools: Annotate fixes, stdio progress indication, debuginfo-client in more places Arnaldo Carvalho de Melo
2026-09-13  2:34 ` [PATCH v1 1/8] perf test: Skip data_type_profiling when the PMU cannot record memory events Arnaldo Carvalho de Melo
2026-09-13  2:40   ` sashiko-bot
2026-09-13  2:34 ` [PATCH v1 2/8] perf debuginfo: Fetch debuginfo keyed by build ID using debuginfod Arnaldo Carvalho de Melo
2026-09-13  2:47   ` sashiko-bot
2026-09-13  2:34 ` [PATCH v1 3/8] perf symbol: Fall back to fetching the vmlinux by build ID Arnaldo Carvalho de Melo
2026-09-13  2:43   ` sashiko-bot
2026-09-13  2:34 ` [PATCH v1 4/8] perf annotate-data: Show the sample count in the data-type browser Arnaldo Carvalho de Melo
2026-09-13  2:43   ` sashiko-bot [this message]
2026-09-13  2:34 ` [PATCH v1 5/8] perf report: Add --progress option Arnaldo Carvalho de Melo
2026-09-13  2:42   ` sashiko-bot
2026-09-13  2:34 ` [PATCH v1 6/8] perf scripts: Add perf-stuck, to tell where a running perf is stuck Arnaldo Carvalho de Melo
2026-09-13  2:44   ` sashiko-bot
2026-09-13  2:34 ` [PATCH v1 7/8] perf annotate-data: Resolve type DIEs in the debug file they came from Arnaldo Carvalho de Melo
2026-09-13  2:44   ` sashiko-bot
2026-09-13  2:34 ` [PATCH v1 8/8] perf mem record: Request PERF_SAMPLE_CPU by default Arnaldo Carvalho de Melo
2026-09-13  2:53   ` sashiko-bot

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=20260913024333.17BB41F00893@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=acme@kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.