其实早在2006年我就用过valgrind，但当时valgrind不能观测daemon的内存泄漏问题，所以后来渐渐用得少了。
今天又遇到一个内存泄漏问题，程序颇大，手工调试不太现实了，所以又想到了valgrind，毕竟在这7年间，valgrind又强大了不少。查了一下，它已经可以检测daemon进程了，方法在这里对应的官方文档在这里其中"monitor leak_check full reachable any"相当于设置gdb的breakpoint。
不过，我要调试的这个程序，一运行就fork了，然后子进程负责主要的逻辑，父进程只是等待子进程返回用的，而且，只在运行某个特殊逻辑时出现内存泄漏，平时的逻辑没有问题。怎么弄？折腾了一下，发现可以搞定：首先，在gdb里运行“set follow-fork-mode child”来自动跟踪子进程，然后，一开始不要急着用”monitor leak_check full reachable any"来检测，先"continue“运行一阵子，当开始跑造成内存泄漏的逻辑时，再ctrl+c打断，再”monitor leak_check full reachable any“设上断点，自然会吐出valgrind的memleak信息。
用这两招，果然找到内存泄漏的点了，隐藏颇深，如果不是用工具，真不知何年何月才能发现。感谢valgrind神器，支持vgdb支持daemon检测，真是杀手级的新特性。(我用的是最新的valgrind-3.9.0，老的valgrind估计不支持)
另外说明一下，我是gdb的小白，以上招数和解释不见得正确或最优，如有行家肯指点，感激不尽。
由 udpwork.com 聚合
|
评论: 0
|
要! 要! 即刻! Now!
