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 jirka > lear > Author: Andrii Nakryiko <andriin@xxxxxx> > Date: Tue Apr 28 18:21:04 2020 -0700 > 1 file changed, 7 insertions(+) > $ make ... > $ perf test 7 > 7: Simple expression parser : Ok > > I'd prefer we took the libbpf fix as initializing over the top of the > hashmap will leak. This fix is in the tools/perf/util/hashmap.c. > > Thanks, > Ian > > >> - Arnaldo > >> > >> > jirka > >> > > >> > > >> > --- SNIP
