Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752521AbbLKD7u (ORCPT ); Thu, 10 Dec 2015 22:59:50 -0500 Received: from mail4.hitachi.co.jp ([133.145.228.5]:55160 "EHLO mail4.hitachi.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751452AbbLKD7r (ORCPT ); Thu, 10 Dec 2015 22:59:47 -0500 From: =?utf-8?B?5bmz5p2+6ZuF5bezIC8gSElSQU1BVFXvvIxNQVNBTUk=?= To: "'Wangnan (F)'" , "'Arnaldo Carvalho de Melo'" CC: Peter Zijlstra , Adrian Hunter , "linux-kernel@vger.kernel.org" , "linux-perf-users@vger.kernel.org" , Ingo Molnar , "Namhyung Kim" , Jiri Olsa , Alexei Starovoitov Subject: RE: [PATCH perf/core 00/22] perf refcnt debugger API and fixes Thread-Topic: [PATCH perf/core 00/22] perf refcnt debugger API and fixes Thread-Index: AQHRMifqdrp25x+uR0WYuBPwTEPEhp7CE3gAgAGJXGD///sdAIAAJ0qAgAFPCED//3HFgIAAqRlA Date: Fri, 11 Dec 2015 03:59:42 +0000 Message-ID: <50399556C9727B4D88A595C8584AAB37526518A7@GSjpTKYDCembx32.service.hitachi.net> References: <20151209021047.10245.8918.stgit@localhost.localdomain> <20151209134138.GB15864@kernel.org> <50399556C9727B4D88A595C8584AAB375264FB48@GSjpTKYDCembx32.service.hitachi.net> <56697572.90701@huawei.com> <20151210151239.GB17996@kernel.org> <50399556C9727B4D88A595C8584AAB37526515F5@GSjpTKYDCembx32.service.hitachi.net> <566A3823.9080503@huawei.com> In-Reply-To: <566A3823.9080503@huawei.com> Accept-Language: ja-JP, en-US Content-Language: ja-JP X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.198.220.44] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id tBB3xt0s006450 Content-Length: 3056 Lines: 63 From: Wangnan (F) [mailto:wangnan0@huawei.com] > > >On 2015/12/11 10:15, 平松雅巳 / HIRAMATU,MASAMI wrote: >> From: 'Arnaldo Carvalho de Melo' [mailto:acme@kernel.org] >>> But this requires having these special refcnt__ routines, that will make >>> tools/perf/ code patterns for reference counts look different that the >>> refcount patterns in the kernel :-\ >> BTW, I think even without the refcnt debugger, we'd better introduce this >> kind API to unify the refcnt operation in perf code. As I said, we have many >> miscodings on current implementation. Unifying the API can enforce developers >> to avoid such miscodings. >> >> Thank you, >> > >I tried this problem in another way, I'd like to share it here. No, what I said here is the issue on the coding policy. If we have no special reason that each object (class) has its own reference counter implementation, we'd better unify it for binding them to one policy. > >Then from perf script's result, search for the two address: > >perf 23203 [004] 665244.170387: probe_perf:dso__new: (4aaee0 <- 50a5eb) >arg1=0x34cb350 > 10a5eb dso__load_sym (/home/w00229757/perf) > af42d dso__load_vmlinux (/home/w00229757/perf) > af58c dso__load_vmlinux_path (/home/w00229757/perf) > 10c40a open_debuginfo (/home/w00229757/perf) > 111d39 convert_perf_probe_events (/home/w00229757/perf) > 603a7 __cmd_probe.isra.3 (/home/w00229757/perf) > 60a44 cmd_probe (/home/w00229757/perf) > 7f6d1 run_builtin (/home/w00229757/perf) > 33056 main (/home/w00229757/perf) > 21bd5 __libc_start_main >(/tmp/oxygen_root-w00229757/lib64/libc-2.18.so) > >perf 23203 [004] 665244.170679: probe_perf:dso__new: (4aaee0 <- 50a5eb) >arg1=0x34d4640 > 10a5eb dso__load_sym (/home/w00229757/perf) > af42d dso__load_vmlinux (/home/w00229757/perf) > af58c dso__load_vmlinux_path (/home/w00229757/perf) > 10c40a open_debuginfo (/home/w00229757/perf) > 111d39 convert_perf_probe_events (/home/w00229757/perf) > 603a7 __cmd_probe.isra.3 (/home/w00229757/perf) > 60a44 cmd_probe (/home/w00229757/perf) > 7f6d1 run_builtin (/home/w00229757/perf) > 33056 main (/home/w00229757/perf) > 21bd5 __libc_start_main >(/tmp/oxygen_root-w00229757/lib64/libc-2.18.so) BTW, actually the analysis of this level (object memory leaks) can be found (and analyzed) by valgrind (please try it). The problem is not happen only when the creating site, but the refcnt can leak when processing the object afterwards. That is the reason why I made refcnt debugger to support precise backtracing for each operation. Thanks, ????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay?ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m???? ????????I?