Re: [PATCH 3/4] 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 4 potential issue(s) to consider:
- [Medium] perf-stuck: hang detection fails if progress log is empty
- [Medium] perf-stuck.gdb: libdw inferior calls lack function pointer casts
- [Medium] perf-stuck.gdb: structure access fails with REFCNT_CHECKING enabled
- [Medium] perf-stuck.gdb: perf-dso macro accesses non-existent dso->name field
--

commit 95092b23c716d33f8c9a4a12147c43af4f703f93
Author: Arnaldo Carvalho de Melo <acme@redhat.com>
Subject: perf scripts: Add perf-stuck, to tell where a running perf is stuck

This commit adds a prototype perf-stuck.sh script to monitor a running perf
process and detect hangs using /proc sampling. If it detects a hang, it uses
perf-stuck.gdb to attach GDB and print the DWARF type chasing loops to
diagnose where it is stuck.

> diff --git a/tools/perf/scripts/perf-stuck.gdb b/tools/perf/scripts/perf-stuck.gdb
> index 0000000000000..ad595392f6beb
> --- /dev/null
> +++ b/tools/perf/scripts/perf-stuck.gdb
[ ... ]
> +define perf-die-chain
[ ... ]
> +      # Pointer type DIEs have no DW_AT_name, so dwarf_diename() can
> +      # return NULL: printf %s of it would error out and abort this
> +      # batch script, handle it.
> +      set $perf_die_chain_name = (char *) dwarf_diename($arg1)
> +      printf "chain[%d] die=%p addr=%p cu=%p off=0x%lx tag=%d name=", $perf_die_chain_i, $arg1, $arg1->addr, $arg1->cu, ((Dwarf_Off) dwarf_dieoffset($arg1)), ((int) dwarf_tag($arg1))

[Severity: Medium]
Will these inferior calls to libdw functions like dwarf_diename(),
dwarf_dieoffset(), and dwarf_tag() fail without explicit function pointer
casts?

Since GDB typically lacks debug information for the shared libdw library, it
does not know the return type of these functions. This can cause modern GDB
to abort the script with an "unknown return type" error.

On older GDB versions, this might truncate the 64-bit pointer return to 32
bits, leading to an invalid memory access during the (char *) cast.

[ ... ]
> +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]
Does struct dso have a name field?

In the perf codebase, struct dso uses short_name and long_name rather than
name. Accessing a non-existent structure field will cause GDB to throw an
error like "There is no member named name" and immediately abort the
execution of the perf-dso macro.

[Severity: Medium]
Will direct structure accesses like dloc->ms->map->dso fail when perf is
compiled with Address/Leak Sanitizers (which enables REFCNT_CHECKING)?

When REFCNT_CHECKING is enabled, reference-counted structures like map and
dso are wrapped in an intermediary proxy struct.

The true data fields are hidden behind an orig pointer, so GDB will throw an
evaluation error like "There is no member named dso" instead of resolving the
fields.

> diff --git a/tools/perf/scripts/perf-stuck.sh b/tools/perf/scripts/perf-stuck.sh
> index 0000000000000..3b9b22124dbda
> --- /dev/null
> +++ b/tools/perf/scripts/perf-stuck.sh
[ ... ]
> +	if [ -n "$prev_cpu" ]; then
> +		cpu_delta=$(( cpu - prev_cpu ))
> +		# With a progress log, count the samples that show no progress,
> +		# without one there is no progress to look at, so count them all:
> +		# -g then looks at where the process is after two intervals.
> +		if [ -z "$progress_log" ] ||
> +		   { [ -n "$progress" ] && [ "$progress" = "$prev_progress" ]; }; then
> +			stuck=$((stuck + 1))
> +		else
> +			stuck=0
> +		fi

[Severity: Medium]
Does this logic unintentionally disable hang detection if a progress log file
is specified but remains empty?

If a progress log file is specified but hasn't been written to (e.g., during
early initialization hangs), the progress variable remains empty. The check
[ -n "$progress" ] evaluates to false, causing the script to fall back to the
else block and unconditionally set stuck=0.

This continuously resets the stuck counter, which will prevent the script
from ever triggering GDB.

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