[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20161009121232.174915eb@kryten>
Date: Sun, 9 Oct 2016 12:12:32 +1100
From: Anton Blanchard <anton@...ba.org>
To: Michael Ellerman <mpe@...erman.id.au>,
Benjamin Herrenschmidt <benh@...nel.crashing.org>,
Paul Mackerras <paulus@...ba.org>,
Nicholas Piggin <npiggin@...il.com>,
ravi.bangoria@...ux.vnet.ibm.com, acme@...hat.com,
peterz@...radead.org, mingo@...hat.com,
alexander.shishkin@...ux.intel.com
Cc: linux-kernel@...r.kernel.org, linuxppc-dev@...ts.ozlabs.orgp
Subject: perf TUI fails with "failed to process type: 64"
Hi,
Updating to mainline as of last night, I started seeing the following
error when running the perf report TUI:
0x46068 [0x8]: failed to process type: 68
This event is just PERF_RECORD_FINISHED_ROUND:
0x46068 [0x8]: event: 68
.
. ... raw event: size 8 bytes
. 0000: 44 00 00 00 00 00 08 00 D.......
0x46068 [0x8]: PERF_RECORD_FINISHED_ROUND
Which of course is not our error. It took me a while to find the real
culprit:
14c00-14c00 g exc_virt_0x4c00_system_call
A zero length symbol, which __symbol__inc_addr_samples() barfs on:
if (addr < sym->start || addr >= sym->end) {
...
return -ERANGE;
Seems like we have 3 bugs here:
1. Output the real source of the error instead of PERF_RECORD_FINISHED_ROUND
2. Don't exit the TUI if we find a sample on a zero length symbol
3. Why do we have zero length symbols in the first place? Does the recent
ppc64 exception clean up have something to do with it?
Anton
Powered by blists - more mailing lists