From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754980AbbK0QDS (ORCPT ); Fri, 27 Nov 2015 11:03:18 -0500 Received: from mail.kernel.org ([198.145.29.136]:42887 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754622AbbK0QDR (ORCPT ); Fri, 27 Nov 2015 11:03:17 -0500 Date: Fri, 27 Nov 2015 13:03:11 -0300 From: Arnaldo Carvalho de Melo To: Jiri Olsa Cc: Jiri Olsa , Namhyung Kim , Linux Kernel Mailing List , masami.hiramatsu.pt@hitachi.com, David Ahern Subject: Re: perf test unwind failing Message-ID: <20151127160311.GD5934@kernel.org> References: <20151126204559.GM28162@kernel.org> <20151127082121.GA24503@krava.brq.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151127082121.GA24503@krava.brq.redhat.com> X-Url: http://acmel.wordpress.com User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.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=) at tests/dwarf-unwind.c:197 > #4 0x000000000045a128 in run_test (test=test@entry=0x888470 , subtest=subtest@entry=-1) at tests/builtin-test.c:241 > #5 0x000000000045a201 in test_and_print (t=t@entry=0x888470 , 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=) at tests/builtin-test.c:416 > #8 0x00000000004782b0 in run_builtin (p=p@entry=0x885d98 , 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 > 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