其实早在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的小白,以上招数和解释不见得正确或最优,如有行家肯指点,感激不尽。