Re: [PATCH] perf timechart: Fix SIBGUS error on sparc64

[Arnaldo Carvalho de Melo]

Em Tue, Mar 24, 2015 at 04:14:09PM -0400, David Ahern escreveu:
> perf timechart -T on sparc64 is terminating due to SIGBUS. Backtrace:
> 
> Program received signal SIGBUS, Bus error.
> 0x0000000000173d7c in perf_evsel__intval (evsel=<value optimized out>, sample=0x7feffffda28, name=0x289b28 "prev_state")
>     at util/evsel.c:1918
> 1918	util/evsel.c: No such file or directory.
> 	in util/evsel.c
> Missing separate debuginfos, use: debuginfo-install audit-libs-2.3.7-1.0.1.el6.sparc64 bzip2-libs-1.0.5-7.el6_0.sparc64 elfutils-libelf-0.155-2.0.3.el6.sparc64 elfutils-libs-0.155-2.0.3.el6.sparc64 glibc-2.12-1.132.0.8.el6_5.sparc64 numactl-2.0.7-8.el6.sparc64 python-libs-2.6.6-52.0.2.el6.sparc64 slang-2.2.1-1.el6.sparc64 xz-libs-4.999.9-0.3.beta.20091007git.el6.sparc64 zlib-1.2.3-29.el6.sparc64
> (gdb) bt
> 0  0x0000000000173d7c in perf_evsel__intval (evsel=<value optimized out>, sample=0x7feffffda28,
>     name=0x289b28 "prev_state") at util/evsel.c:1918
> 1  0x0000000000123b94 in process_sample_sched_switch (tchart=0x7feffffe040, evsel=0x4ca850, sample=0x7feffffda28,
>     backtrace=0xc39010 "") at builtin-timechart.c:627
> 2  0x0000000000122828 in process_sample_event (tool=0x7feffffe040, event=<value optimized out>, sample=0x7feffffda28,
>     evsel=0x4ca850, machine=0x4c9c88) at builtin-timechart.c:569
> 
> Another extended load on unaligned pointer. As before fix by copying to

Humm, so this is being put that way by the tracepoint in the kernel?
Lemme see...

It is this one, right?

[root@ssdandy ~]# cat /t/events/sched/sched_switch/format
name: sched_switch
ID: 228
format:
	field:unsigned short common_type;	offset:0;	size:2;	signed:0;
	field:unsigned char common_flags;	offset:2;	size:1;	signed:0;
	field:unsigned char common_preempt_count;	offset:3;	size:1;	signed:0;
	field:int common_pid;	offset:4;	size:4;	signed:1;

	field:char prev_comm[16];	offset:8;	size:16;	signed:1;
	field:pid_t prev_pid;	offset:24;	size:4;	signed:1;
	field:int prev_prio;	offset:28;	size:4;	signed:1;
	field:long prev_state;	offset:32;	size:8;	signed:1;
	field:char next_comm[16];	offset:40;	size:16;	signed:1;
	field:pid_t next_pid;	offset:56;	size:4;	signed:1;
	field:int next_prio;	offset:60;	size:4;	signed:1;

print fmt: "prev_comm=%s prev_pid=%d prev_prio=%d prev_state=%s%s ==> next_comm=%s next_pid=%d next_prio=%d", REC->prev_comm, REC->prev_pid, REC->prev_prio, REC->prev_state & (1024-1) ? __print_flags(REC->prev_state & (1024-1), "|", { 1, "S"} , { 2, "D" }, { 4, "T" }, { 8, "t" }, { 16, "Z" }, { 32, "X" }, { 64, "x" }, { 128, "K" }, { 256, "W" }, { 512, "P" }) : "R", REC->prev_state & 1024 ? "+" : "", REC->next_comm, REC->next_pid, REC->next_prio
[root@ssdandy ~]#

---------------------------------------------

I.e. this should be reading from the ring buffer, where this info was put, all aligned, by the kernel,
except when we need to use struct perf_mmap->event_copy, that is...

struct perf_mmap {
        void             *base;
        int              mask; 
        int              refcnt;
        unsigned int     prev;
        char             event_copy[PERF_SAMPLE_MAX_SIZE] __attribute__((aligned(8)));
};

sizeof(u64) aligned, no?

/me scratches head, should be missing something embarassingly simple :-/

- Arnaldo


> a temporary variable using memcpy.
> 
> Signed-off-by: David Ahern <david.ahern@xxxxxxxxxx>
> ---
>  tools/perf/util/evsel.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
> index daa053d..ef20371 100644
> --- a/tools/perf/util/evsel.c
> +++ b/tools/perf/util/evsel.c
> @@ -1925,7 +1925,7 @@ u64 perf_evsel__intval(struct perf_evsel *evsel, struct perf_sample *sample,
>  		value = *(u32 *)ptr;
>  		break;
>  	case 8:
> -		value = *(u64 *)ptr;
> +		memcpy(&value, ptr, sizeof(u64));
>  		break;
>  	default:
>  		return 0;
> -- 
> 1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/