From: Ingo Molnar <mingo@kernel.org>
To: linux-perf-users@vger.kernel.org, Ian Rogers <irogers@google.com>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>,
Namhyung Kim <namhyung@kernel.org>,
Mark Rutland <mark.rutland@arm.com>, Jiri Olsa <jolsa@kernel.org>,
Ian Rogers <irogers@google.com>
Subject: [PATCH] Fix (well, work around) perf stat --null segfault
Date: Sun, 30 Nov 2025 12:43:43 +0100 [thread overview]
Message-ID: <aSwt7yzFjVJCEmVp@gmail.com> (raw)
JFYI:
starship:~> perf stat --null ls
Segmentation fault (core dumped)
Program received signal SIGSEGV, Segmentation fault.
0x000055555563596e in __perf_cpu_map__nr (cpus=<error reading variable: Cannot access memory at address 0x0>) at cpumap.c:257
257 return RC_CHK_ACCESS(cpus)->nr;
(gdb) bt
#0 0x000055555563596e in __perf_cpu_map__nr (cpus=<error reading variable: Cannot access memory at address 0x0>) at cpumap.c:257
#1 perf_cpu_map__max (map=0x0) at cpumap.c:372
#2 0x00005555555cc249 in perf_stat_init_aggr_mode ()
#3 0x00005555555d1963 in cmd_stat ()
#4 0x0000555555631bb2 in run_builtin ()
#5 0x0000555555631e9e in handle_internal_command ()
#6 0x00005555555ab183 in main ()
(gdb)
(gdb) print cpus
Cannot access memory at address 0x0
(gdb) bt
#0 0x000055555563596e in __perf_cpu_map__nr (cpus=<error reading variable: Cannot access memory at address 0x0>) at cpumap.c:257
#1 perf_cpu_map__max (map=0x0) at cpumap.c:372
#2 0x00005555555cc249 in perf_stat_init_aggr_mode ()
#3 0x00005555555d1963 in cmd_stat ()
#4 0x0000555555631bb2 in run_builtin ()
#5 0x0000555555631e9e in handle_internal_command ()
#6 0x00005555555ab183 in main ()
(gdb)
For some build(?) reason I cannot set breakpoints
inside builtin-stat.c:
(gdb) b builtin-stat.c:1545
No source file named builtin-stat.c.
... and didn't investigate any further.
System has 128 CPUs.
It's been broken for some time:
starship:~/tip> git bisect bad
ced4c249569ab25c32b0d36e2ebdb19c74394bdf is the first bad commit
commit ced4c249569ab25c32b0d36e2ebdb19c74394bdf (HEAD)
Author: Ian Rogers <irogers@google.com>
Date: Fri Jul 18 20:05:05 2025 -0700
perf stat: Don't size aggregation ids from user_requested_cpus
As evsels may have additional CPU terms, the user_requested_cpus may
not reflect all the CPUs requested. Use evlist->all_cpus to size the
array as that reflects all the CPUs potentially needed by the evlist.
Reviewed-by: Thomas Falcon <thomas.falcon@intel.com>
Signed-off-by: Ian Rogers <irogers@google.com>
Tested-by: James Clark <james.clark@linaro.org>
Link: https://lore.kernel.org/r/20250719030517.1990983-4-irogers@google.com
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
The bug is the assumption that
evsel_list->core.all_cpus exists at this stage.
The attached patch works this around like the old
version, but there's more things wrong with this code:
BTW., I couldn't even find where all_cpus pointer gets
allocated. It gets zalloc()-ed to NULL, and cleared
back to NULL in two places:
lib/perf/evlist.c: evlist->all_cpus = NULL;
lib/perf/evlist.c: evlist->all_cpus = NULL;
But where does it get allocated? perf_cpu_map__nr()
hides it in most cases that ->cpus_all is always NULL:
int perf_cpu_map__nr(const struct perf_cpu_map *cpus)
{
return cpus ? __perf_cpu_map__nr(cpus) : 1;
}
Which in general is a code robustness red flag, for
something this fundamental I doubt there should be any
conditionality to this pointer. Allowing cpus pointers
to be NULL and hiding it in the helpers hid a real bug
for months.
So this code looks like a bit of a trainwreck. ;-)
In addition to fixing the bug, it might also make sense
to add a testcase for 'perf stat --null'? (which is a
better, more accurate 'time' utility)
As an additional report and side note, I still get this
bogus message during a build on standard Ubuntu:
Makefile.config:1151: No openjdk development package found, please install JDK package, e.g. openjdk-8-jdk, java-latest-openjdk-devel
The suggested "e.g. openjdk-8-jdk" package *is*
installed:
starship:~/tip> dpkg -l | grep openjdk
ii openjdk-11-jre:amd64 11.0.29+7-1ubuntu1~25.10 amd64 OpenJDK Java runtime, using Hotspot JIT
ii openjdk-11-jre-headless:amd64 11.0.29+7-1ubuntu1~25.10 amd64 OpenJDK Java runtime, using Hotspot JIT (headless)
ii openjdk-17-jre:amd64 17.0.17+10-1~25.10 amd64 OpenJDK Java runtime, using Hotspot JIT
ii openjdk-17-jre-headless:amd64 17.0.17+10-1~25.10 amd64 OpenJDK Java runtime, using Hotspot JIT (headless)
ii openjdk-21-jre:amd64 21.0.9+10-1~25.10 amd64 OpenJDK Java runtime, using Hotspot JIT
ii openjdk-21-jre-headless:amd64 21.0.9+10-1~25.10 amd64 OpenJDK Java runtime, using Hotspot JIT (headless)
ii openjdk-8-jdk:amd64 8u472-ga-1~25.10 amd64 OpenJDK Development Kit (JDK)
ii openjdk-8-jdk-headless:amd64 8u472-ga-1~25.10 amd64 OpenJDK Development Kit (JDK) (headless)
ii openjdk-8-jre:amd64 8u472-ga-1~25.10 amd64 OpenJDK Java runtime, using Hotspot JIT
ii openjdk-8-jre-headless:amd64 8u472-ga-1~25.10 amd64 OpenJDK Java runtime, using Hotspot JIT (headless)
Thanks,
Ingo
====================>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
tools/perf/builtin-stat.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index 7006f848f87a..973b72218df7 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -1542,7 +1542,10 @@ static int perf_stat_init_aggr_mode(void)
* taking the highest cpu number to be the size of
* the aggregation translate cpumap.
*/
- nr = perf_cpu_map__max(evsel_list->core.all_cpus).cpu + 1;
+ if (evsel_list->core.all_cpus)
+ nr = perf_cpu_map__max(evsel_list->core.all_cpus).cpu + 1;
+ else
+ nr = 0;
stat_config.cpus_aggr_map = cpu_aggr_map__empty_new(nr);
return stat_config.cpus_aggr_map ? 0 : -ENOMEM;
}
next reply other threads:[~2025-11-30 11:43 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-30 11:43 Ingo Molnar [this message]
2025-12-01 16:52 ` [PATCH] Fix (well, work around) perf stat --null segfault Ian Rogers
2025-12-01 17:54 ` Ingo Molnar
2025-12-01 23:33 ` 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=aSwt7yzFjVJCEmVp@gmail.com \
--to=mingo@kernel.org \
--cc=acme@kernel.org \
--cc=irogers@google.com \
--cc=jolsa@kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=namhyung@kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).