Em Sun, May 24, 2020 at 12:19:36AM +0200, Jiri Olsa escreveu: > On Fri, May 22, 2020 at 10:56:59AM -0700, Ian Rogers wrote: > > SNIP > > > >> > #11 0x00000000004b6911 in cmd_test (argc=1, argv=0x7fffffffd7f0) > > >> > at tests/builtin-test.c:772 > > >> > #12 0x00000000004e977b in run_builtin (p=0xa7eee8 > > >> > <commands+552>, argc=3, argv=0x7fffffffd7f0) at perf.c:312 > > >> > #13 0x00000000004e99e8 in handle_internal_command (argc=3, > > >> > argv=0x7fffffffd7f0) at perf.c:364 > > >> > #14 0x00000000004e9b2f in run_argv (argcp=0x7fffffffd64c, > > >> > argv=0x7fffffffd640) at perf.c:408 > > >> > #15 0x00000000004e9efb in main (argc=3, argv=0x7fffffffd7f0) at > > >> > perf.c:538 > > >> > > > >> > attached patch fixes it for me, but I'm not sure this > > >> > should be necessary > > >> > > >> ... applying the patch below makes the segfault go away. Ian, Ack? I can > > >> fold it into the patch introducing the problem. > > > > > > > > > I suspect this patch is a memory leak. The underlying issue is likely the > > > outstanding hashmap_clear fix in libbpf. Let me check. > > > > > > Thanks, > > > Ian > > > > Tested: > > $ git checkout -b testing acme/tmp.perf/core > > $ make ... > > $ perf test 7 > > 7: Simple expression parser : FAILED! > > $ git cherry-pick 6bca339175bf > > [acme-perf-expr-testing 4614bd252003] libbpf: Fix memory leak and > > possible double-free in hashmap__c > > yep, it fixes the issue for me, but I see that under different commit number: > > 229bf8bf4d91 libbpf: Fix memory leak and possible double-free in > hashmap__clear
Ok, so I'll just add a note mentioning that this test will pass as soon as the libbpf fix gets upstream. Thanks, - Arnaldo
