Re: [PATCH v2 6/8] perf scripts: Add perf-stuck, to tell where a running perf is stuck

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The `perf-dso` GDB macro uses invalid C syntax to access fields of the `ms` struct pointer, causing evaluation to fail.
--

commit 78fb763d9dbe173145a580fdc9c3bef811e7fc40
Author: Arnaldo Carvalho de Melo <acme@redhat.com>

perf scripts: Add perf-stuck, to tell where a running perf is stuck

This commit adds a script and a GDB command file to help identify where a
running perf process is stuck. The script samples the process at fixed intervals
to detect unbound loops or recursion, and can optionally invoke GDB to print the
DIE chain when no progress is made.

> diff --git a/tools/perf/scripts/perf-stuck.gdb b/tools/perf/scripts/perf-stuck.gdb
> new file mode 100644
> index 0000000000000..12a3f2952a68c
> --- /dev/null
> +++ b/tools/perf/scripts/perf-stuck.gdb
[ ... ]
> @@ -0,0 +1,104 @@
[ ... ]
> +define perf-dso
> +  if $_any_caller_is("find_data_type", 20)
> +    frame function find_data_type
> +    printf "dso=%s ip=0x%lx sym=%s\n", dloc->ms.map->dso->name, dloc->ip, dloc->ms.sym->name

[Severity: Medium]
Will this macro fail with a GDB evaluation error when running
perf-stuck.sh -g? If ms is a pointer to struct map_symbol, GDB's C evaluator
requires the -> operator.

Should this be accessed as dloc->ms->map->dso->name and dloc->ms->sym->name
instead?

> +  else
> +    printf "not in find_data_type()\n"
> +  end
> +end

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