一、前言
其实对 C/C++ 的应用来说,查看函数时间调用和内存消耗调用的有很多工具,valgrind 这个工具算是做得比较不错的一个。建议直接用 yum 安装,有的说可以安装更新的版本,像我这种不喜欢各种找依赖条件的,就直接 yum 了。
二、快速使用
1、查看内存越界和泄露的情况
它的使用也非常简单,比如下面这个例子,可以查看内存越界和泄露的情况。只要用 valgrind 调用一下被测试的程序即可。
memcheck:
[root@7dgroupSample10]# vi test5.c
[root@7dgroupSample10]# gcc -Wall -o test5 test5.c
[root@7dgroupSample10]# valgrind --tool=memcheck --leak-check=full ./test5
==318==Memcheck, a memory error detector
==318==Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==318==Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==318==Command: ./test5
==318==
==318== Invalid write of size 4 //内存越界
==318== at 0x40054E: f (in/root/GDB/Sample10/test5)
==318== by 0x40055E: main (in/root/GDB/Sample10/test5)
==318== Address 0x51f7068 is 0bytes after a block of size 40 alloc'd
==318== at 0x4C29BFD: malloc(in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==318= by 0x400541: f (in/root/GDB/Sample10/test5)
==318= by 0x40055E: main (in/root/GDB/Sample10/test5)
==318==
==318==
==318==HEAP SUMMARY:
==318== in use at exit: 40 bytes in 1 blocks
==318== total heap usage: 1 allocs, 0 frees, 40bytes allocated
==318==
==318== 40 bytes in 1 blocks are definitely lost in loss record 1 of 1 //内存泄露
==318== at 0x4C29BFD: malloc(in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==318== by 0x400541: f (in/root/GDB/Sample10/test5)
==318== by 0x40055E: main (in/root/GDB/Sample10/test5)
==318==
==318==LEAK SUMMARY:
==318== definitely lost: 40 bytes in 1 blocks
==318== indirectly lost: 0 bytes in 0 blocks
==318== possibly lost: 0 bytes in 0 blocks
==318== still reachable: 0 bytes in 0 blocks
==318== suppressed: 0 bytes in 0 blocks
==318==
==318==For counts of detected and suppressed errors, rerun with: -v
==318==ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 1 from 1)
[root@7dgroupSample10]#
再看一下它的其他工具:
cachegrind: Cache分析器,可以查看引用次数,命中率等信息。
[root@7dgroupSample10]# valgrind --tool=cachegrind ./test5
==1655==Cachegrind, a cache and branch-prediction profiler
==1655==Copyright (C) 2002-2013, and GNU GPL'd, by Nicholas.NEThercote et al.
==1655==Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==1655==Command: ./test5
==1655==
--1655--warning: L3 cache found, using its data for the LL simulation.
--1655--warning: specified LL cache: line_size 64 assoc 20 total_size 31,457,280
--1655--warning: simulated LL cache: line_size 64 assoc 30 total_size 31,457,280
==1655==
==1655== I refs: 152,928
==1655== I1 misses: 765
==1655== LLi misses: 759
==1655== I1 miss rate: 0.50%
==1655== LLi miss rate: 0.49%
==1655==
==1655== D refs: 51,260 (39,547 rd + 11,713 wr)
==1655== D1 misses: 2,861 ( 2,321 rd + 540 wr)
==1655== LLd misses: 2,384 ( 1,891 rd + 493 wr)
==1655== D1 miss rate: 5.5% ( 5.8% + 4.6% )
==1655== LLd miss rate: 4.6%( 4.7% + 4.2% )
==1655==
==1655== LL refs: 3,626 ( 3,086 rd + 540 wr)
==1655== LL misses: 3,143 ( 2,650 rd + 493 wr)
==1655== LL miss rate: 1.5%( 1.3% + 4.2% )
[root@7dgroupSample10]#
callgrind: 查看函数调用关系及时间消耗
[root@7dgroupSample10]# valgrind --tool=callgrind /usr/sbin/Nginx
==1713==Callgrind, a call-graph generating cache profiler
==1713==Copyright (C) 2002-2013, and GNU GPL'd, by Josef Weidendorfer et al.
==1713==Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==1713==Command: /usr/sbin/nginx
==1713==
==1713==For interactive control, run 'callgrind_control -h'.
==1713==
==1713==Events : Ir
==1713==Collected : 8916001
==1713==
==1713==I refs: 8,916,001
[root@7dgroupSample10]# ll
总用量 884
-rw-------.1 root root 5047 4月 17 21:12 cachegrind.out.1655
-rw-------.1 root root 129128 4月 17 21:15callgrind.out.1702
-rw-------. 1 root root 128813 4月 17 21:16 callgrind.out.1713
这个结果可以生成调用图。
如下所示:
还可以用 kcachegrind(有 linux 和 windows 版本)打开 out 文件。
如下所示 :
在这个图的下面还有一个百分比图例,直接双击可以一层层 drill down下去,直到一个具体的函数。也可以直接看到相应的源码(前提是有 ELF 文件)。
三、总结
这个工具有它的局限性,就是它不能 attach 进程。如果要查看运行中的进程的内存消耗和函数消耗情况,可以使用其他工具。有感兴趣的以后我再写如何查看运行中的C/C++剖析工具。
工具用好了事半功倍,但是前提是理解原理。
转载于
https://blog.csdn.net/zuozewei/article/details/118460011?utm_medium=distribute.pc_feed_v2.none-task-blog-yuanlijihua_tag_v1-2.pc_personrecdepth_1-utm_source=distribute.pc_feed_v2.none-task-blog-yuanlijihua_tag_v1-2.pc_personrec