Re: [PATCH] perf stat: Fix crash on arm64

[Breno Leitao <leitao@debian.org>]

On Mon, Mar 23, 2026 at 10:06:37AM -0700, Ian Rogers wrote:
> On Wed, Mar 11, 2026 at 4:50 AM Leo Yan <leo.yan@arm.com> wrote:
> >
> > Hi Breno,
> >
> > On Wed, Mar 11, 2026 at 03:21:00AM -0700, Breno Leitao wrote:
> > > On Thu, Feb 05, 2026 at 10:22:27AM -0800, Ian Rogers wrote:
> > > > I think it is a different issue, they have metrics while you don't.
> > > > Your report does highlight we're missing a NO_JEVENTS=1 build-test,
> > > > but the build is working for me. I'll send out two patches for these
> > > > issues.
> > >
> > > Hi Ian, Leo, Acme
> > >
> > > I wanted to follow up on this. Are there any next steps I should take?
> >
> > Sorry for not tracking this issue.
> >
> > I can reproduce the issue on my Orion6 with setting a _dummy_ CPUID:
> >
> >  $ export PERF_CPUID=0x00000000410fd490
> >  $ perf stat -C 5 -vvv
> >  ...
> >  Aborted
> >  perf: util/evsel.c:2156: get_group_fd: Assertion `!(!leader->core.fd)' failed
> >
> > Because we are working on different hardwares, I am a bit suspect I
> > reproduced the issue with difference sequence as yours.  Anyway, I do
> > see that an event can be opened prior to its leader event, see the log
> > below.
> >
> > Thus, your patch seems make sense to me as we need to ensure the leader
> > event to be opened first.  Ian, how about you think?
> 
> Because so many things depend on the event ordering, the patch makes
> me very nervous, particularly how it will change architectural
> requirement handling. Ordering the Intel slots and metric events is a
> challenge. There is also how handling uncore events, which are
> deliberately parsed out-of-order, will change. I've got a feeling the
> test coverage for this isn't adequate, and finding the bugs requires
> running on particular machines. It will also require examining the
> default perf stat output to ensure this isn't broken; hopefully the
> code is somewhat robust.

Sure thing. please let me know if there is any action on my side, and
I am happy to help.

> Ideally, the impact of the change on all these issues would be in the
> commit message, but it's more realistic to cover each issue with
> testing. I'll try to ask an AI buddy to help with this. Could you
> rebase and send a v2? I'm curious to see what sashiko will throw up.

Ack. I will resping it, so, we can check what sashiko thinks about it.

Thanks,
--breno