Re: perf test unwind failing

[Arnaldo Carvalho de Melo <acme@kernel.org>]

Em Fri, Nov 27, 2015 at 09:21:21AM +0100, Jiri Olsa escreveu:
> On Thu, Nov 26, 2015 at 05:45:59PM -0300, Arnaldo Carvalho de Melo wrote:
> > 	Can you take a look at 'perf test unwind'? It is failing in my
> > perf/core branch, no time to bisect that now.
> > 
> > [root@zoo ~]# perf test unwind
> > 40: Test dwarf unwind                                        : FAILED!
> 
> (gdb) set follow-fork-mode child
> (gdb) r test dwarf
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x7ffff7fd2780 (LWP 29735)]
> 0x00000000004ac953 in map__kmap (map=map@entry=0x7ffff7ffe4a0) at util/map.c:839
> 839             if (!map->dso || !map->dso->kernel) {
> (gdb) bt
> #0  0x00000000004ac953 in map__kmap (map=map@entry=0x7ffff7ffe4a0) at util/map.c:839
> #1  0x00000000004a97a2 in machine__destroy_kernel_maps (machine=machine@entry=0x7fffffffdb80) at util/machine.c:807
> #2  0x00000000004a9861 in machine__exit (machine=machine@entry=0x7fffffffdb80) at util/machine.c:125
> #3  0x0000000000477669 in test__dwarf_unwind (subtest=<optimized out>) at tests/dwarf-unwind.c:197
> #4  0x000000000045a128 in run_test (test=test@entry=0x888470 <arch_tests+80>, subtest=subtest@entry=-1) at tests/builtin-test.c:241
> #5  0x000000000045a201 in test_and_print (t=t@entry=0x888470 <arch_tests+80>, force_skip=force_skip@entry=false, subtest=subtest@entry=-1)
>     at tests/builtin-test.c:268
> #6  0x000000000045a42b in __cmd_test (argc=argc@entry=1, argv=argv@entry=0x7fffffffe3d0, skiplist=0x0) at tests/builtin-test.c:324
> #7  0x000000000045a707 in cmd_test (argc=1, argv=0x7fffffffe3d0, prefix=<optimized out>) at tests/builtin-test.c:416
> #8  0x00000000004782b0 in run_builtin (p=p@entry=0x885d98 <commands+504>, argc=argc@entry=2, argv=argv@entry=0x7fffffffe3d0) at perf.c:387
> #9  0x00000000004784ad in handle_internal_command (argc=2, argv=0x7fffffffe3d0) at perf.c:448
> #10 0x0000000000478518 in run_argv (argcp=argcp@entry=0x7fffffffe23c, argv=argv@entry=0x7fffffffe230) at perf.c:492
> #11 0x0000000000478789 in main (argc=2, argv=0x7fffffffe3d0) at perf.c:609
> (gdb) q
> 
> 
> it's caused by following commit:
>   commit ebe9729c8c3171aa46ad5d7af40acdc29806689d
>   Author: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
>   Date:   Wed Nov 18 15:40:24 2015 +0900

Humm, affects just machine__exit(), how could it cause problems here?
 
> it kind of assumes that __machine__create_kernel_maps is called ono
> machine, but we don't do that in the tests/dwarf-unwind.c,

Must be some other patch (see below).

> only following initialization:
> 
>         machines__init(&machines);

Well, if you want to deal with a machine that supports a kernel, then
you need to create the kernel maps, if all you want to do is to deal
with userspace samples, why would you spend time on that?
 
>         machine = machines__find(&machines, HOST_KERNEL_ID);
>         if (!machine) {
>                 pr_err("Could not get machine\n");
>                 return -1;
>         }
> 
> 
> we could call machine__create_kernel_maps right here to fix the issue,
> (please check attached patch), but I wonder what's the proper interface
> we want to have for creating machine..

See above.

After reading the patch I see why you refer to that patch, it is just
that at machine__exit() one should free the kernel maps if they were
created, so it calls machine__destroy_kernel_maps(), and that will check
if the maps were allocated, if not, nothing will be done.

Anyway, I applied your patch, it fixes the problem, thanks!

- Arnaldo