RE: [PATCH perf/core 00/22] perf refcnt debugger API and fixes

[åæéå / HIRAMATUïMASAMI]

From: Wangnan (F) [mailto:wangnan0@xxxxxxxxxx]
>
>
>On 2015/12/11 10:15, åæéå / HIRAMATUïMASAMI wrote:
>> From: 'Arnaldo Carvalho de Melo' [mailto:acme@xxxxxxxxxx]
>>> 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‹§²æ¸›yú²X¬¶ÇvØ–)Þ{.nlj·¥Š{±‘êX§¶›¡Ü}©ž²ÆzÚj:+v‰¨¾«‘êZ+€Êzf£¢·hšˆ§~†­†Ûÿû®w¥¢¸?™¨è&¢)ßf”ùy§m…á«a¶Úÿ0¶ìå