linux-kernel - Re: [PATCH] perf top: fix crash on annotate request

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 30 Nov 2011 16:10:11 -0200
From:	Arnaldo Carvalho de Melo <acme@...radead.org>
To:	Brian Marete <marete@...hnix.com>
Cc:	David Ahern <dsahern@...il.com>, linux-kernel@...r.kernel.org,
	mingo@...e.hu, peterz@...radead.org, fweisbec@...il.com
Subject: Re: [PATCH] perf top: fix crash on annotate request

Em Wed, Nov 30, 2011 at 04:23:17PM +0300, Brian Marete escreveu:
> On Fri, Nov 11, 2011 at 1:01 AM, Brian Marete <marete@...hnix.com> wrote:
> >
> > Hello,
> >
> > On Thu, Oct 20, 2011 at 4:00 PM, Arnaldo Carvalho de Melo
> > <acme@...stprotocols.net> wrote:
> > > I.e. the map_ip for this method is messing up things, what symbol is
> > > this? I.e. please provide:
> > >
> > > p *sym
> > > p *map
> >
> > I have am experiencing the same segfault using perf from the latest
> > linus' tree. The gdb backtrace is below. Which patch fixes it? Or is
> > it already fixed in some git tree on kernel.org?
> >
> > Thanks
> >
> > Program received signal SIGSEGV, Segmentation fault.
> > 0x000000000042e27e in symbol__inc_addr_samples (sym=0x1279e70, map=0x9677a0,
> >    evidx=0, addr=256544) at util/annotate.c:73
> > 73              h->addr[offset]++;
> > #0  0x000000000042e27e in symbol__inc_addr_samples (sym=0x1279e70, map=
> >    0x9677a0, evidx=0, addr=256544) at util/annotate.c:73
> > #1  0x00000000004215e4 in record_precise_ip (he=0x1e7b260, counter=0,
> >    ip=256544) at builtin-top.c:223
> > #2  0x0000000000422ba1 in perf_event__process_sample (event=0x7ffff7ec4c60,
> >    evsel=0x837a10, sample=0x7fffffffe340, session=0x837e80)
> >    at builtin-top.c:801
> > #3  0x0000000000422c8c in perf_session__mmap_read_idx (self=0x837e80, idx=1)
> >    at builtin-top.c:825
> > #4  0x0000000000422d43 in perf_session__mmap_read (self=0x837e80)
> >    at builtin-top.c:839
> > #5  0x0000000000423295 in __cmd_top () at builtin-top.c:1003
> > #6  0x0000000000423940 in cmd_top (argc=0, argv=0x7fffffffe720, prefix=0x0)
> >    at builtin-top.c:1274
> > #7  0x000000000040ffdc in run_builtin (p=0x6a4bc8, argc=1, argv=0x7fffffffe720)
> >    at perf.c:286
> > #8  0x00000000004101af in handle_internal_command (argc=1, argv=0x7fffffffe720)
> >    at perf.c:358
> > #9  0x00000000004102b5 in run_argv (argcp=0x7fffffffe60c, argv=0x7fffffffe600)
> >    at perf.c:402
> > #10 0x00000000004104f8 in main (argc=1, argv=0x7fffffffe720) at perf.c:512
> >
> > # Output of p *sym
> > $1 = {rb_node = {rb_parent_color = 19423281, rb_right = 0x0, rb_left = 0x0},
> >  start = 1124896, end = 1126163, namelen = 16, binding = 0 '\000',
> >  ignore = false, name = 0x1279e70 "1`(\001"}
> >
> > # Output of p *map
> > $2 = {{rb_node = {rb_parent_color = 9861408, rb_right = 0x967860, rb_left =
> >    0x9676e0}, node = {next = 0x967920, prev = 0x967860}}, start = 4142972928,
> >  end = 4144365568, type = 0 '\000', referenced = true, priv = 0, pgoff = 0,
> >  map_ip = 0x44fc69 <map__map_ip>, unmap_ip = 0x44fc92 <map__unmap_ip>, dso =
> >    0x8e5490, groups = 0x964cd8}
> 
> Hello. I can still reproduce this every time with the tip Linus' tree.
> Is there a tree that fixes this? I beginning to wonder if anyone uses
> `perf top' :)

Can you try with:

https://github.com/acmel/linux/tree/perf/core

It just fell thru the cracks, sorry, I should have tried to reproduce
and fix this on the tree you reported.

But if you can try with the above tree...

Persistence is key, thanks for using it :)

- Arnaldo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/