Valgrind 是一套类似于 gprof 的动态检测的工具集,由于使用方便,不需修改目标程序源码,输出清晰图文并茂等优势,常被用作后台(特别是linux后台)服务内存泄漏检测、性能打点、竞态检测等。
a. 去官方网站 http://valgrind.org/downloads/current.html 下载最新安装包,如 valgrind 3.13.0 (tar.bz2) 解压;
b. 常规源码编译安装:./autogen.sh; ./configure; make; make install;
c. 安装成功 valgrind --version 输出版本号;
3.1 内存泄漏检测:
a. 正常编译目标程序 (如 g++ -g -o valgrind_tst main.cpp),官方推荐加上 -g 选项;
b. valgrind --tool=memcheck --leak-check=full --log- file=memchk.log valgrind_tst [Your progame option];
c. --tool=memcheck 表示使用工具集中的内存检测,其他选项参考 valgrind -h;
d. 特别的 --trace-children = yes 开启这个选项将使 valgrind 追踪到子进程,但据说不是很好用,所以我一般将服务设置为前台运行,如果你的后台服务(daemon 进程)无法设置前台运行,可以尝试这个选项;
e. 结果输出,直接 vi memchk.log(由命令中的 --log-file 指定)查看:
结果中比较重要的是:
definitely lost: 确定有内存泄漏,表示在程序退出时,该内存无法回收,也没指针指向该内存(首地址);
indirectly lost: 间接内存泄漏,比如结构体中定义的指针指向的内存无法回收;
possibly lost: 可能出现内存泄漏,比如程序退出时,没有指针指向一块内存的首地址了,但由其他某个指针能推算出首地址;
still reachable: 程序没主动释放内存,在退出时候该内存仍能访问到,比如全局 new 的对象没 delete,由于操作系统会回收,所以此类问题可忽略;
最严重的是 definitely lost 和 indirectly lost,检测结果文件中已给出了具体函数和源文件。
3.2 性能检测(调优):
a. 正常编译目标程序同上;
b. valgrind --tool=callgrind -v Your_Programme [Your_Programe_Option];
c. --tool=callgrind 表示使用调用检测工具,同样,建议在前台运行;
d. 由于 callgrind 的原理是时间点采样,所以被测程序最好在合适的压力下运行合适长的时间;
e. 查看结果,运行完后,将输出 callgrind.out.PID 文件,该文件可被 gprof2dot 等工具解析转化为 dot,再由 dot 转化为图片输出,也可以直接用 callgrind_annotate 直接解析打印,但最方便的是使用图形工具解析,如 windows 上的 qcachegrind;
f. qcachegrind 安装略,以下是 qcachegrind 打开上述 callgrind.out.PID 文件的效果:
左边列出了调用parts、调用栈 cost 排序等,右边列出了所有调用者、被调用者以及调用图等。
g. 分析程序的性能损耗在哪,可以选择左侧 Flat File --> group by ELF object,找到感兴趣的 object 文件:
h. Self表示自身执行的耗时,Incl表示包含调用函数的总耗时,选择感兴趣的函数,在右边可查看该函数的调用关系图:
i. 根据耗时分布找到程序的性能瓶颈,针对性的优化,关于 qcachegrind 的详细说明,可查阅官网 http://kcachegrind.sourceforge.net/html/Home.html ;
在 callgrind 的调用图中发现这个:
它是什么呢,有什么用呢?
在下篇文章《ld_XXXX.so 在你不小心 rm -f /* 时的作用》在聊 :D
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。